top of page

Sprint Review Playbook


The Sprint Review is the Team's opportunity to demonstrate what they delivered in the previous Sprint to the Product Owner and stakeholders so they can receive feedback, learn and adapt.

It represents the 'inspect and adapt' cycle for the Product.

There are 4 steps in this Playbook:

  1. Preparation

  2. Share the details of the previous Sprint

  3. Demonstrate the items delivered

  4. Seek feedback and learn


  • Inspect the deliverables completed in the Sprint.

  • Adapt the Product Backlog based on feedback

  • Learn about business and customer value

  • Replaces status updates, Sprint Review provides much greater visibility than a traditional status update

  • Replaces 'go / no go' meetings as decisions about what to release are confirmed in the Sprint Review

  • Helps the Team to develop pride in what they are delivering

  • Uplifts stakeholder engagement and connection to the Team


  • All Team Members

  • Scrum Master

  • Product Owner

  • Invited Stakeholders



3 - Moderate


30 minutes - 1 hour


Sprint Backlog and Artefacts

Delivered Product Features

Meetings to cancel when you set up your Sprint Review

  • Status updates

  • Go / no go meetings, (assuming your 'Definition of Done' actually means Done!)

  • Showcase (at a Team level, you might retain a showcase at the project or portfolio level)

3 - Moderate.png


Ensure the right people are in the room

One of the key dysfunctions we see in many Sprint Reviews is the lack of participation from customers, stakeholders and leaders.  This results in the Team reviewing their Sprint to themselves, not only is this wasteful, but it eliminates the 'inspect and adapt' cycle for the product so we are unable to learn and we cannot improve our backlog.

ABC: Always Be Capturing

Be ready to capture feedback as it emerges.  Comments may happen during the review of the Sprint or the demonstration of the product.  It can be helpful to ask a Team Member to be the scribe for the Sprint Review and be ready to note down any comments or feedback either directly into the relevant Priduct Backlog Items or separately as notes you can use after the event.

Ensure the product is ready to demonstrate

Neither your Team nor your stakeholders want to sit around while you bring up the system, log in and navigate through all the layers of product that they are already familiar with.  Having everything ready to demonstrate prior to the Sprint Review will save a lot of time that is better spent collecting feedback and discussing what the newly delivered items mean for the product and for the product backlog.

Ensure participation from Team Members

It is a good idea to involve the participation of as many Team Members as possible.  Ask the Team to self organise around who will demonstrate each item delivered, ideally every Team Member will be able to demonstrate something they collaborated on delivering.

Share the details of the previous Sprint

An honest and open discussion of how things went in the previous Sprint:

  • The Sprint Goal

    • Was it achieved?​

    • Was it helpful?

    • Did anything need to adapt in order to achieve it?

  • The Sprint Backlog

    • Was anything removed from the Sprint Backlog during the Sprint?  If so, why?​

    • Was anything added to the Sprint Backlog?  Why?

  • Your Sprint Metrics

    • Sprint Burndown​

    • Release Burnup

  • The Sprint itself

    • How did the work flow?​

    • How did the Team operate?

    • What learnings emerged during the Sprint?

    • What help was required from outside the Team?

    • What help was received from outside the Team?

  • Retro action the Team focused on during the Sprint​

    • The Retro action​

    • The success measure and what was achieved

    • The outcome of the retro action


Rather than this being a one-way presentation from the Scrum Master or Product Owner, make it a conversation.

Thank any stakehlders or leaders who helped out.


When thanking a Team Member for something great they did, ask them to share a little about what happened or why it was necessary.

Demonstrate the items delivered

Maintaining the focus on the Sprint Goal, share the outputs from the Sprint.

  • Introduce each deliverable and its acceptance criteria

  • Demonstrate each deliverable

  • Discuss how it contributes to the Sprint Goal, your roadmap and your product vision, invite questions and comments from stakeholders

Magnifying Glass

Seek feedback and learn

When all items have been demonstrated, seek feedback from stakeholders regarding how they feel about the Sprint and the progress the Team has made.

  • Does the output from the Sprint align with their expectations?

  • Now that stakeholders have seen what was delivered, does it influence their perception of our next priorities?

Discuss readiness to release the completed deliverables to customers.  If your Team is unable to continuously deploy or release on demand, you will want to confirm the suitability of deliverables for release.  Decisions made in your Sprint Review will feed into your Release Planning and replaces the need for a 'go / no go' meeting.

Review the backlog and next priorities.

Keep notes of stakeholder feedback and any actions arising so you can incorporate it into your Sprint Comms.

bottom of page