What is Done During Sprint Review Meeting?

The Sprint Review Meeting is an important part of the Inspect and Adapt cycle of Scrum. It’s a simple meeting really. Mastering the Sprint Review meeting though is quite rare.

According to the Scrum Guide:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

That final sentence is key but so often missed.

Mastering the Sprint Review means it is NOT a Sprint Demo

Sure, there should be a demonstration of the functionality that has been delivered. This is absolutely crucial. Talking about functionality is boring and makes it easy to hide real progress behind words and intent. The true measure of progress of a Sprint is “what can we do now that we couldn’t before?”

The first trick to mastering the Sprint Review meeting is to make sure the demonstration is smooth, informative and quick.

A great Sprint Review will have clear, concise demos that effectively convey the progress that has been made. These demos should be well-prepared and visually appealing, and should highlight key achievements and challenges.

Sometimes the people doing the demonstration will be the Developers, sometimes it will be the Product Owner, sometimes it will be the users themselves. In my experience the best demonstrations actually involve handing over the functionality to the users and seeing if they can intuitively use it without having to have it explained or showcased.

But the demonstration is just one part of mastering the Sprint Review meeting.

A Great Sprint Review Looks Forward As Well As Back

In my book Scrum Mastery, I write:

A good ScrumMaster facilitates the sprint review to look back and review the product built in the previous sprint.

A great ScrumMaster facilitates the sprint review to look forward and shape the product in future sprints.

I’ve been in many Sprint Review meetings where attendees have seen the new functionality that has been delivered and it has generated some interesting discussion points. These discussions are arguably more valuable than the functionality.

For example, I’ve seen users say:

“Oh, wow…now we can do THAT, it would be REALLY useful if we could do THIS.”

Quite often, “THIS” isn’t something on the Product Backlog or on the roadmap and, while that can initially be frustrating, discovering this information is ultimately what an agile approach is all about. Many of our users don’t know what they want until they can see something. Once we’ve shown them something, that’s the best time to actually understand real user needs.

The conversation then needs to move to “how should we change our future plans to best accommodate the new information we have now?”

A Sprint Review meeting can also highlight opportunities to improve how we work.

Another thing I have heard often at Sprint Review meetings is:

“Oh…I see what you’ve done there but that’s not how we would use it”

The Scrum team will often need to make some educated decisions about usability. Some of those decisions will be spot on, some of them will actually lead to better ways of doing things than users might have thought of if they had been asked in advance. Sometimes though, when users see a solution, the feedback is that we got it wrong.

And that’s a great thing, for two reasons. Firstly we have learned this sooner than we might have done. And secondly, we have now identified a benefit of closer collaboration between the people who want things and the people who are building them.

As well as demonstrating the new functionality that has been delivered this sprint, I always encourage teams to consider a number of questions at the end of every sprint.

8 Questions for Mastering the Sprint Review

New Requirements?

Have we identified any new functionality that we now need? Sometimes new requirements emerge during the sprint or seeing what is now possible sparks an idea in someone about what could be done next.

New Priorities?

Have the priorities changed? For example, has the reporting feature suddenly dropped down in importance while the security feature is now more critical? Sprint reviews are a great opportunity to shift priorities around to suit the current state of the project. Perhaps one item from the product backlog is now no longer required at all, in which case it could be removed from the product backlog altogether.

New Estimates?

Have our estimates changed? The sprint review is a time for the development team to revisit their estimates against some empirical data to give a more accurate view of the team’s velocity. Equally important is the chance to change the estimate of something the team have yet to start because of the new information gathered during this sprint.

New Velocity?

Has our velocity changed? The team now have another data point about how much work they are capable of completing within a sprint. By revisiting their velocity projection, they should be able to increase their certainty about the likely end date or the likely scope.

New Design?

Does the design need to change? Scrum teams embrace the concept of emergent design and, as such, should revisit the design of the product at least at the end of every sprint to ensure that it remains sensible, with integrity and that they build in the appropriate amount of refactoring.

New Release?

Can we release? Ideally Scrum teams should be in a position where they could release the increment at the end of every sprint if they so decide. This might not always be the case and so we may use this information to guide our release and/or marketing strategy.

New Process?

Should we change our process? Most of this will be covered in the subsequent Sprint Retrospective but there may be some elements of this that it would be appropriate to discuss with the wider audience present for the sprint review. For example, access to UAT, team composition, feature acceptance criteria and so on.

New Plan?

If we answer all of these seven questions then we will inevitably have a new plan or at least a new view on the future of the product. Then it’s up to the Product Owner whether to carry on with the product development by sanctioning another Sprint or not.

Mastering The Sprint Review

Overall, a great sprint review is one that is highly effective at helping everyone understand the progress that has been made and identify areas for improvement in our product, our plan and our working practices.

All of these questions contribute to the overall aim of updating the plan to reflect the information that the team have now. Ultimately, the team, product owner and stakeholders must decide if this is a project that they wish to continue investing in, which is a much more valuable output from the sprint review than a mere demonstration of functionality