My response is usually, “No…I mean the Sprint Review. A demo is only the inspect portion of inspect-and-adapt. A Sprint Review is an opportunity to inspect the Product Increment and to adapt the Product Backlog.” In my experience, Scrum Teams tend to focus too much time on “inspect” and not enough time on “adapt.” In this post, I will share thoughts and recommendations on organizing an effective Sprint Review.

Structuring an Effective Sprint Review

The Sprint Review is a deliberate pause at the end of each Sprint to allow the stakeholders, and ideally customers, the opportunity to provide the Scrum Team feedback on the value delivered in the Sprint and for everyone to talk about what is planned next. To ensure this meeting remains a dialogue, I recommend the following structure:

  1. The Product Owner sets the stage for what to expect during the Sprint Review.  Often the Product Owner will identify the Sprint Goal and provide a broader context to help stakeholders understand overall progress to date.
  2. The Development Team demonstrates the Potentially Releasable Product Increment to the stakeholders, possibly including its underlying architecture.
  3. Stakeholders give real-time feedback on the product and evaluate if the Scrum Team delivered on the Sprint Goal. Attendees ask questions during the demonstration. Open-ended questions, such as “How well does this meet your expectations?” lead to valuable feedback about the product. 
  4. Next, attention is turned to the Product Backlog, including any items that did not meet the Definition of “Done.” Both the stakeholders and Scrum Team discuss how the feedback they received, and any new business context provided by the stakeholders, may impact the ordering of the Product Backlog.
    This is also the time to review where the Scrum Team is, in the context of the next release, through tools such as a Release Burndown. Any new information about changing customer needs, competitors, or the marketplace in general, is also discussed between the Sprint Team and stakeholders. For Sprint Reviews without customers, the budget and organizational impediments are also discussed.
  5. Finally, everyone collaborates on what to do next. For example, perhaps the Scrum Team should release earlier than expected; or, after two Sprints the conclusion reached is that the innovative idea for a new product is not viable and the Scrum Team should pivot to new work. In most cases, everyone focuses on the plan for the next Sprint. 

A Sample Sprint Review Agenda

1.Welcome, expectation setting – PO, SM

  1. Why hold a Sprint Review – first time
  2. Introduce Stakeholders – first time, new stakeholders

2.Set expectations for the review – PO – first time

  1. Collaborative working session
  2. Ensure business value is delivered
  3. Review working software produced during the Sprint

3.Share Sprint or Product Increment goals – PO

  1. Connect to review roadmap and/or release plan
  2. Set context on where the Sprint is in the overall effort — release or increment
  3. Focus less on the individual user stories, and more on the value created
  4. Answer ”How does this Sprint add value to the overall product iteration?”

4.Review Value Delivered – The Team

  1. Share the value the team achieved
  2. Demonstrate working software
  3. Solicit feedback from Stakeholders on how well the team achieved the objective

5.Provide feedback on the Product Increment – Stakeholders

6.Share what is planned for the next Sprint – PO

7.Celebrate, have some fun – All 

The key takeaway is to ensure the Sprint Review is recognized as an event to make critical business decisions about product development.

Clearly Defined Roles are Critical

To have an effective Sprint Review, everyone has a part to play. Here are some recommended responsibilities to get you started.

Stakeholders

A good bit is written about what the Product Owner, ScrumMaster, and Development Team members do in Scrum, but not much about stakeholder responsibilities. I suspect the main reason for this lack of detail is that during a Sprint there are not that many Scrum-specific activities for stakeholders. However, that isn’t the case during the Sprint Review. In a Sprint Review, stakeholders are both audience and actors. Here are a few key responsibilities to consider:

  1. Show up: this is probably one of the most important things a stakeholder can do. This important role is to share additional business context about organizational needs, current and prospective customer needs, news about competitors and insights into what possible future features would be valuable. By actively participating as often as possible, stakeholders send the message that what the Scrum Team is doing is important to them and the business. 
  2. Understand the Sprint Goal: if stakeholders do not know the Sprint Goal, they should ask. If the Sprint Goal is not aligned with their goals, do not panic! That feedback should be given to the Product Owner and dialogue should ensure about how to get back on track.
  3. Ask questions: stakeholders should interact with a working, high-quality product increment at the end of every Sprint and ask about anything that does not seem quite right. The Sprint Review is intended to be a dialogue, so expect communication and questions to flow in both directions.
  4. Be open: incremental product development is probably different than what most stakeholders have experienced in the past. Just because something does not work exactly the way they envisioned does not mean customers are not getting value from what the Scrum Team delivered or that it cannot be changed in the future. Keep standards high, but be patient.

Pro Tip: The “same time, same place” mantra of the Daily Scrum should also apply to the Sprint Review. This will help Stakeholders get into the rhythm of the Scrum team vs. the Scrum Team getting into the rhythm of the Stakeholders.

Product Owner

  • Invite the right stakeholders: it seems fairly obvious, but in order to receive feedback, the Product Owner needs to create a list of people to invite to the Sprint Review. Unless you invite them, most stakeholders will not show up. If you are familiar with the Power vs. Interest framework by Fran Ackermann and Colin Eden, from their book Making Strategy, you can use that to evaluate who to invite. Be sure to invite your Players to the Sprint Review. Subjects and Context Setters are also good people to invite, but secondary.
  • Provide context: next up is to set expectations with the stakeholders. It is very important to help the stakeholders understand what type of participation is needed for a collaborative Sprint Review, what type of feedback will be helpful, and how they can prepare. For stakeholders unfamiliar with Scrum, working with Scrum Teams, or Agile in general, leverage your partnership with your ScrumMaster to help educate stakeholders on basic concepts.
  • Nail the logistics: identifying the right time and location for the Sprint review,  whether in-person or virtual, is crucial to getting it on a stakeholder’s calendar. In my experience, the invitation should come from you, the Product Owner, in order to maximize stakeholder attention. Over the years, I have learned not to rely solely on a calendar invitation. Personal emails, phone calls and in-person invitations will increase participation dramatically.

ScrumMaster

  • Ensure the Sprint Review happens: partner with the Product Owner to ensure that he or she knows the importance of the Sprint Review as an event to inspect-AND-adapt. Help the Product Owner identify which stakeholders need to attend and educate any holdouts on the importance of their participation and feedback.
  • Coach the Development Team: work with the Development Team to guide them on how to prepare and deliver an impactful demonstration of the potentially releasable product Increment. Helping the Development Team members articulate the business impact of what they delivered is crucial. If not, Sprint Reviews quickly become a status report of what “tickets” were completed and stakeholders will rapidly lose interest. In fact, don’t mention tickets or stories at all. Demonstrate experiences and explain delivery of value resulting from the Sprint.

Pro Tip: After format changes to the Sprint Review, ScrumMasters should carve out time to specifically get feedback on any changes in format or Stakeholders during the Sprint Retrospective.

Development Team 

  • Be present & engaged: the Sprint Review is the Development Team’s opportunity to interact directly with stakeholders of the product. It is important that members of the team put their best foot forward, so I recommend taking at least a small amount of time to prepare. Try a dry run of the demonstration at the end of the day before the Sprint Review. Share and celebrate what the team has accomplished in the Sprint and be honest about your setbacks. In most cases, the stakeholders want to help, so use this opportunity to engage them and ask for help.
  • Talk in terms of business value: stakeholders want to know that the Development Team understands the business impact of what they are building. During the Sprint, the Development team should ask the Product Owner questions to ensure they are clear on the business value of what is being delivered and playback that understanding during the Sprint Review. The more they speak in language familiar to stakeholders, the more likely the Scrum Team will unlock a treasure trove of valuable business context and feedback crucial for the product’s success. 

Pro Tip: Ensure that you include time to prepare for the Sprint Review in Sprint Planning. This can take the form of developing a “review harness” to demonstrate value when not leveraging a UI or taking time to perform a dry run prior to the Sprint Review. 

Party On: Wrapping Up a Sprint Review

And finally, celebrate! An effective Sprint Review can be that place where the Scrum Team and stakeholders come together for serious, powerful collaboration, but it is also a time to celebrate, all together, the hard work the Scrum Team has accomplished before they plunge into the next Sprint.

“A common mistake is that Sprint Reviews become boring meetings. Instead, a review meeting should be a party! Stakeholders and customers are present, so show them the business value that has been created.” – Rini van Solingen

*Written by Kevin Rosengren