What happens during a sprint review?

“Ooh! look at that exciting new feature.”

Recently at work, we’ve been looking at standardising certain tools and events such as sprint reviews. This post looks at what a sprint review is and offers a suggested agenda.


Suggested sprint review agenda

  1. Set the scene
    • Is the sprint board up-to-date?
    • What were the sprint goals?
    • What will be demonstrated?
  2. Look back at what went well and what didn’t
    • What problems and impediments were uncovered during the sprint?
    • Why did they happen?
    • What has been done or is being done to remove them?
    • What process improvements have been put in place?
  3. Demonstrate stories that have met the definition of done
    • Demo done stories.
    • Optional demo of ‘coming soon’ features (if absolutely necessary).
  4. Look forward
    • How does what we learned today impact our future plans?
  5. Close the meeting


In Scrum, very near the end of each sprint, two important events are held that help teams to inspect how they are doing and make adjustments as required: the sprint review and the sprint retrospective.

These events are usually held in that order: review then retrospective. One often feeds the other. The sprint review looks at the current state of the product being developed and how that affects the overall product backlog; the sprint retrospective then explores the processes, people, relationships and tools within the team to most efficiently deliver the plan to build the next iteration.

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. (Source: Scrum Guide)

These three pillars are most evident in the sprint review.

Not just a demo

For many, the sprint review has become synonymous with a demonstration of the progress made during the sprint: walking people through the new features and bug fixes that have been completed. But as Declan Wheelan is quoted as saying, “sprint review isn’t just a demo. Let stakeholders see the truth so guidance comes from an informed position.”

Geoff Watts in Scrum Mastery (Inspect & Adapt, 2013) notes that the difference between a good Scrum team and a great Scrum team is that while the good team’s sprint review looks back and reviews the product built during the last sprint, a great team’s sprint review also looks forward to shape the product in future sprints.

There is often a common misconception that the sprint review is an opportunity for the product owner to accept or reject work done on the sprint and provide feedback to the team. While circumstances may require this to happen from time to time, it should be the exception rather than the rule. Ideally, this should be done throughout the sprint so that only work that is completed (meets the definition of done) is touched on and demonstrated during the review meeting.

The primary objective of the sprint review is for the product owner to get feedback from stakeholders, and based on that feedback adjust the plan accordingly by adapting the product backlog

Sprint review agenda

So, how might a team best use their sprint review to both look back and forward?

Combining some of the best ideas that I’ve found from various Scrum resources, the following agenda might be used and adapted for your sprint review. There are five sections to the meeting:

  1. Set the scene
  2. Look back at what went well and what didn’t
  3. Demonstrate stories that have met the definition of done
  4. Look forward
  5. Close the meeting

Let’s look at these in a little more detail, starting with what preparation might be required.


Preparation for the sprint review begins at the sprint planning meeting. Anticipate what might be said about this new feature during the review, what data might be needed to demonstrate it?

Early on, figure out whom to invite. Who will bring most value, domain knowledge and insights for how to move forward? One benefit of agile is about getting the right people in the room at the right time. There may be a core group of people who should be invited to every sprint review and then a select group who may invited to the occasional review to give their input

If a room has not already been booked, this will also need to be done. Consider what equipment will be required and make sure that’s in place and working before the review. Also consider the size and layout of the room for those who are attending.

During the sprint, write the presentation script if needed, and create the demo data. Include this work within your estimate for that user story.

1. Set the scene

On the day, the purpose of the first part of a sprint review is to effectively set the scene for everyone present, especially if there are stakeholders who many not have attended sprint planning meetings or daily scrums.

It can be helpful at this point to show the end-of-sprint status of the burndown chart.

Is the sprint board up-to-date?

I will often ask the team to confirm that the sprint board (a physical board or Jira or Trello or whatever the team is using) accurately reflects the current state. Are cards in the right columns, have cards been commented on, etc? Ideally, this will have been done before the sprint review but I find it useful to confirm this at the start of the sprint review. If there are stakeholders available, this can offer them an insight into how we work and how transparent we try to be.

What were the sprint goals?

The scrum master will now invite the product owner (or members of the development team) to explain what the goals of the sprint were and whether they were met or not.

Remember, this is a blame-free meeting. If something did go wrong and the sprint goal wasn’t met, it isn’t helpful to try to attribute blame on someone. In keeping with Scrum and agile principles, allow the process to reveal the dysfunction and use it to determine how best to move forward.

What will be demonstrated?

Next, explain that only items that have met the definition of done will be demonstrated. If any stakeholders are new to the product, it can be helpful to explain what the definition of done is and how it is used.

Outline the items from the sprint backlog that will be demonstrated so people know what will be coming up.

2. Look back at what went well and what didn’t

Looking back at the sprint, the product owner, development team and scrum master should now identify what went well during the sprint and what didn’t. This is supports the Scrum values of courage, openness and respect within the Scrum pillars of transparency, inspection, and adaptation.

Problems and impediments

Discuss what problems and impediments were uncovered during the sprint. Why did they happen? What has been done or is being done to remove them? What process improvements have been put in place to improve things in the future? Do any stakeholders present have any ideas?

While this feedback can be taken into the retrospective, it’s important to raise it here. Remember, the purpose of the sprint review is to examine the current state of the product being developed and determine how that affects the future plan, and that includes impediments.

3. Demonstrate stories that have met the definition of done

We now reach the sprint demonstration.

The team should decide before the meeting who is running the demonstration and have everything set up and ready to go before the sprint review begins. It could be one developer or tester, or shared among the team with different people introducing different features and fixes. Sometimes, the product owner may wish to ‘drive’ the demonstration.

Using any scripts that may have been written during the sprint, the appointed team member should demonstrate each new feature or bug fix that has met the definition of done. Where applicable, this should be demonstrated from the perspective of an end user. Feedback and questions are welcome from the rest of group.

Demonstrating this potentially-releasable increment becomes the focal point for an in-depth discussion about the product. Encourage comments and discussion but try to avoid in-depth problem-solving.

The demonstration is meant to be low-fi but with high value. The team shouldn’t spend a long time producing polished PowerPoint slides. The focus should be on working software. Remember the second statement from the Agile manifesto: we value working software over comprehensive documentation.

Only completed work will be demonstrated, however, if required the team may also demo a few ‘coming soon’ features that are still being developed.

4. Look forward

With the demonstration over, the final part of the sprint review ties together what has happened during the previous sprint with a plan for the future. With any questions answered and new ideas recorded, the product owner may now discuss what the team will do next.

The outcome of this meeting will be used as an input into subsequent sprint planning meetings, refinement, etc. In other words, how does what we learned today impact our future plans? How might we need to adapt what we are doing to best meet the needs of the customer?

This could be:

  • New velocity
  • New estimates
  • New processes
  • New design
  • New requirements
  • New priorities
  • New releases
  • New projected milestones
  • New plan

Any actions that come out of the sprint review should be documented and SMART (specific, measurable, achievable, relevant and time-bound) and assign someone to be responsible for each.

5. Close the meeting

With the sprint review complete, the team now has an opportunity to ask the customer to accept this potentially-shippable increment for deployment and then close the sprint review meeting which brings the sprint to a formal end.

Photo by You X Ventures on Unsplash

Published by

Gareth Saunders

I’m Gareth J M Saunders, 52 years old, 6′ 4″, father of 3 boys (including twins). Enneagram type FOUR and introvert (INFP), I am a non-stipendiary priest in the Scottish Episcopal Church, I sing with the NYCGB alumni choir, play guitar, play mahjong, write, draw and laugh… Scrum master at Safeguard Global; latterly at Sky and Vision/Cegedim. Former web architect and agile project manager at the University of St Andrews and previously warden at Agnes Blackadder Hall.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.