Sprint Review – Key To Higher ROI

Sprint ReviewScrum teams are expensive. Salaries and the other costs of maintaining a team represent a significant investment. A well run sprint review can dramatically improve the return your organization gets on this investment (ROI). Sadly, sprint review is widely misunderstood, and poorly implemented. The result is wasted time and lost opportunity. Let’s explore how to unlock the value of sprint review.

What Is Sprint Review

Each of the events in scrum implement feedback loops allowing the team to inspect-and-adapt. Thus we constantly course-correct in order to have better and better outcomes. Sprint review is the event where we close the feedback loop about the product itself.

I think of sprint review as the town hall meeting between the team and the stakeholder community. The stakeholder community may include: end users, customers, sales, support, management, and other teams whose work is dependent on this team’s work. Together, we inspect-and-adapt the plan for the product by repeatedly updating the answers to key questions such as:

  • How well does the current product meet the needs and expectations of the stakeholders?
  • How is our knowledge of the cost and timelines for building the product evolving?
  • How is our understanding of the market changing?
  • In what ways are the assumptions we’ve had about our product and market not quite correct?
  • What aspects of the product plan should be changed to better fit our latest understanding?

The outcome of sprint review is a shared understanding of how we will change the product plan, in order to build an even more valuable product. These changes will manifest as new or changed items in the product backlog.

Start With A Demonstration

The first part of sprint review is often called the demo. This is where the scrum team demonstrates what has been delivered this sprint. The goal is to get everybody on the same page about the current reality of the product.

A demo is more powerful than a status update. If the team simply tells stakeholders what features were implemented this sprint, then the stakeholders will have different beliefs and expectations about those features and how they work. Whereas, if we all sit together and actually see a demonstration of each feature, then we all have the same, much more correct, understanding of what was created.

Next, The Stakeholders Speak

After the demo, the team engages with stakeholders to gather information. Some of the information will be feedback about the demo. Perhaps someone might say, “Oh, I don’t like that the chart goes directly from green to red. There should be a yellow transition period in there.” We’ll capture that feedback. It becomes a new request which may ultimately become a new product backlog item.

Sometimes, we will get feedback that sounds more like this: “Oh yes, you built exactly what we asked for. Now that we see it, we realize it won’t meet our needs. We actually need something a little bit different.” It can feel upsetting to receive this sort of feedback, but it’s actually very valuable. It will keep us from investing more time building the wrong thing. Now we can talk about what they really need, and change our upcoming product backlog accordingly.

Stakeholders will often have input unrelated to the demo. Perhaps a customer made a brand new request. Perhaps our competitor announced a new version of their product and we want to move the release date of our product, in response.

A savvy product owner will facilitate a business value estimation activity as part of their sprint review. In such an activity, the stakeholders assign and adjust value estimates for each of the items in the product backlog. This is very similar to how the developers create and adjust effort estimates for the items in the product backlog. By relating the value estimate to the effort estimate, an ROI can be assigned to each item in the product backlog. This helps tremendously with prioritization.

Finally, Change The Plan To Increase ROI

This is the most important part of sprint review. The product owner leads an assessment of the product backlog, looking for ways to improve it. The product owner discusses when the upcoming items might be implemented and what additional involvement will be needed from the stakeholders to refine the items. This is an opportunity to verify assumptions, ask questions, and get additional clarity. Importantly, it is where we will adjust the product backlog to incorporate all of the new information that has come to light during this sprint review. This is how the stakeholders guide the scrum toward creating an ever more valuable product, increasing the ROI of the development effort.

Further Reading




Share it!

Leave a Reply

Your email address will not be published. Required fields are marked *