8 Best Practices to Start a Scrum Project

Currently I’m writing a series of blog posts about the retrospective I facilitated during Scrum Day Europe. I’ll describe the strength of Scrum, experienced frustrations, small improvements and also what should be the focus the upcoming years. For the latter the participants suggested Scrum should focus on creating value-driven organizations. While doing some research on this idea I stumbled upon an old blog post I wrote two years ago: ‘6 Best Practices to Kick Start Your Scrum Team‘. The idea was to copy a small part of this article but I ended up rewriting the entire blog post. The result is what you’re currently reading. After this blog post I’ll continu the series based on the Scrum Day Europe retrospective.

Customer Collaboration over Contract Negotiation

The purpose of Scrum is to create ‘done’, usable, and potentially releasable increments. Increments that deliver value to customers each iteration. Increments that delight the customer.

A truly value-driven organization also embraces value-driven contracts. These are contracts that have a foundation build on transparency and trust. Such a contract stimulates effective partnerships and invites collaboration. A value-driven contract supports adapting new insights and processing gained knowledge. It encourages acting on necessary changes and lessons learned. A value-driven contract is lightweight and only contains the necessary agreements and constraints. A value-driven contract embraces the Agile mindset.

In reality however, agreeing upon an Agile, value-driven contract is difficult. When the customer has a great idea, enthusiasm is high and possibilities are endless. We only have to agree upon the contract…

The difficulty with contracts is that it’s all about trust. If there’s enough mutual trust in each other’s capabilities, setting up a contract probably won’t be too difficult. But often the customer and supplier haven’t worked together before, therefore it lacks a proven foundation of trust. The customer wants guarantees around budget, time, quality and scope. A decent change control process is lacking. After some tough negotiations the development team starts but doesn’t truly collaborate with the customer and is just mechanically building what’s written in outdated requirements. A suboptimal product will be the result and the relationship and trust is damaged deeply.

But how to gain trust when you haven’t worked together before?

How to start a new Scrum project and setup a contract that focuses on outcome instead of output?

To answer these questions I’ll share some best practices. Mainly written from my experience working for a web agency as a supplier, completed with fulfilled Prowareness engagements.  This is also the perspective I use. The customer is an external client asking support for a software development project.

8 Best Practices to Start a Scrum Project

1. Create the Product Vision & Product Backlog Together

Often the customer has an idea about the product and it’s possibilities but a Product Backlog is still missing. A good practice is to organise a workshop with the customer and the supplier’s Development Team and letting them create the Product Backlog together. Even before setting up the contract. Ideally you also create the product vision to ensure mutual understanding. By creating the product vision and Product Backlog together the customer and supplier really get to know each other. More important: the customer meets the actual Development Team. They are the ones who are going to realise his dream. They are the ones he needs to trust.

2. Estimate the Implementation Effort of the Product Backlog Together

After creating the Product Backlog together it’s also possible to estimate it in the presence of the customer. The advantage is the customer hears all the discussions & questions and can answer them directly. Possible complexity is also detected and discussed together which ensures mutual understanding about the given estimations.


3. Determine the Business Value of the Product Backlog Together

When the Product Backlog is estimated in implementation effort, the next step is determining the business value. This is up to the stakeholders. In the same session, facilitate the stakeholders to discuss and determine the business value for every Product Backlog Item using business value points. The goal is a shared understanding of the priorities and inviting the stakeholders to participate in defining what is more valuable. This exercise forces them to prioritize the Product Backlog without delegating this responsibility entirely to the Product Owner.

After estimating the implementation effort (done by the Development Team) and determining the business value (done by the stakeholders) the following matrix will appear. This offers great insights like:

  • PBI D, E, F and G have a low implementation effort and lot’s of business value. So start with these items first.
  • PBI H and I will take quite some effort to implement and won’t offer much business value. So do we really want this on the Product Backlog?


4. Clarify Dependencies Between Product Backlog Items

When the implementation effort and business value is determined for every Product Backlog Item, it’s time to detect the dependencies. Technical dependencies can be clarified by the Development Team, functional dependencies might also be detected by the Product Owner and stakeholders. This offers insights like:

  • PBI C is a bottleneck. Discuss this item in more detail to solve the dependencies.
  • PBI J and K also have a dependency, so take this into account when ordering the Product Backlog


5. Start Small

Even when a customer has a huge budget for his project, first agree upon doing only one Sprint. After you’ve created and estimated the product vision and Product Backlog together, only do the first Sprint with the goal of delivering the first ‘done’, valuable and potentially releasable increment. Perform a Sprint Review and Sprint Retrospective and decide if there’s enough mutual trust to start another Sprint.

6. Invite the Customer to the Scrum Events

Invite the customer to all the Scrum events. Let the customer experience how the Daily Scrum is done, let them experience the discussions during the Sprint Planning and share all the lessons learned during the Sprint Review. Most important of course is to gather feedback about the delivered product and evaluate the collaboration.

7. Sell the Entire Scrum Team

Fixed Scrum Teams that have been working together for a longer period, have experienced up’s & down’s and know there velocity are worth gold. A common pitfall is to separate this ‘golden team’ when a new project arrives. Don’t do this. Keep the team together at all costs. The customers gets the entire team, including tester, analist, designer, Scrum Master, developers etc.

8. Sell Sprints

When working with fixed teams that know their velocity, it’s also easier to sell sprints for this team. Of course velocity is something for the team, will take 3 -5 Sprints to discover and can vary with every product they build. However, a fixed, experienced team knows what they are capable of, can estimate a Product Backlog and give a range of how much Sprints the realisation will probably take, for example: between 5 – 7 Sprints.

Because the team is fixed they also know what the costs per sprint are, for example 40.000,-. This means the necessary budget for this project will be between 200.000,- and 280.000,- During every Sprint Review, the Scrum Team and stakeholders can discuss the desired features that should be developed the upcoming Sprint. They can discuss how much value the will get taking the cost per Sprint into account. By selling Sprints the advantage for the customer is the possibility of early termination of the contract. When the cost of continuing the project is higher than the additional value received, there is the possibility of just not buying any more Sprints.

What’s Your Opinion?

In the end, it’s all about trust. Creating the product vision & Product Backlog together, estimating the Backlog, determining the business value and dependencies, starting small and inviting the customer to the Scrum sessions are all practices to build this necessary foundation of trust. When there’s a foundation of trust it also becomes easier to sell the entire Scrum Team and sell Sprints with a focus on business value. And of course, quickly delivering valuable, working software is the ultimate way to gain trust.

When the described examples are applied more often within organizations, the possibility of truly becoming a value-driven organization also increases. My hope for the upcoming years is that organizations that use Scrum, also use contracts that respect the Agile mindset and start new Scrum projects with a focus true collaboration.

What are best practices for Agile contracts that worked for you? Would love to know your point of view!

Want help with setting this up in your organization? Contact me at info@barryovereem.com

2 thoughts to “8 Best Practices to Start a Scrum Project”

  1. Hi Barry,

    that’s a really interesting approach, thank you very much for sharing! I’m curently acting as a PO in a frontend team, containing 3 developers & 3 designers. Even though I agree with your approach in a higher level, there are several factors to be taken into consideration when a new project arrives to a Product team:

    * Are there currently other ongoing projects being implemented?

    In big organizations, the possibility of a project to be running exclusively on its own by a team is (close to) zero. The Product Backlog is a living artifact, so any new project will become part of the artifact, rather than live on its own there until it’s released. This comes with a higher round of negotiations with the stakeholders, according to the values you expressed on your 2-4 points, in which different projects’ iterations are being negotiated, which can (and possibly will) extend the delivery time of the project overall.

    * Is the # of stakeholders adequate for the team to afford Creating the Product Backlog, Estimating it and Calculating the Business Value and RoI together?

    In highly exposed teams, judging by personal experience, where the Product is visible and the stakeholders number is large, involving them into the Scrum team’s rituals (apart from the Sprint Review of course) can prove a real delaying & frustrating factor. In order to achieve a smooth interaction, either the stakeholders should be trained in Scrum (or Agile methodologies in general) so to understand their influence limits (i.e. they shouldn’t participate/influence the estimation process in other ways than shedding lights into dark ereas that may compromise the effort estimation), or their influence to the Scrum Team should be kept to minimum, with the PO being the single responsible point of reference when it comes to the ‘what’ part (as Scrum suggests).

    * Does the new project contain graphic/web design? How is the design justified?

    The idea of the MVP, small iterations with working software deliveries in every sprint, is only feasible after a certain point within a project’s life cycle. Especially when containing design, a new project will certainly need time (at least 1 sprint, depending on the overall size of the project), in order to gather the specifications and come up to an agreement according to the UI, by using wireframes, mockups, interactions etc. Now, depending on the stakeholders number, the amount of time needed to gather feedback and finalize the look ‘n feel MVP may increase significantly.
    Even in design-oriented agile methodologies, like Lean-UX or alternatives, the quick iterations start to make sense after the original idea has been sketched and presented on paper (/digital wireframes). This mostly happens because the wireframes may indicate interactions, details or ideas that hadn’t been exposed in the initial project brief and could result into different effort estimations.
    What my team and I are trying to achieve, is for the applied design Product Backlog Items to be at least 1 sprint/2 weeks ahead of the implementation, which seems to be worth the time investment.

    Even though I understand that you’re mosly referring to projects having a certain limited lifetime, your points can easily be scaled onto more complex Product Teams. These above are some of my biggest not-sufficiently solved trouble-makers in my Scrum life as a PO and thought that they’re worth sharing.

    I would be glad to hear your opinion and experiences so far regarding these matters!


  2. There is always a dilemma in the mind of a project manager when it comes to starting a Scrum Project. This article gives a neat 8 step guideline which will certainly help PMs to understand the approach towards starting a project.

Comments are closed.