How do I run a Sprint Review?

The Sprint Review is one of five events in Scrum. It’s purpose is to inspect the Increment of work, get feedback, and then adapt the Product Backlog. And while many people refer to the Sprint Review as the “demo” or “showcase”, this is only one aspect of the Sprint Review.

Empiricism

Like all Scrum’s events, the Sprint Review is a mechanism of empiricism – inspecting the potentially releasable Increment and adapting the Product Backlog by capturing feedback and adding new Product Backlog items. The Sprint Review is a mechanism to inspect what was delivered in order to adapt, improve and introduce changes into the next Sprint. 

Who attends?

  • The Product Owner.
  • The Agile Team who did the work.
  • The Scrum Master.
  • Stakeholders and other interested parties.

What does the Sprint Review involve?

  • The Product Owner explains to the people at the event what Product Backlog items meet the Definition of Done, and which items don’t.
  • The Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved. This provides everyone with insight into how the Team delivered its work in a self-organising way.
  • The Team don’t then discuss how to improve on these actions – that’s a task for the Retrospective.
  • The Team demonstrates the work that it has “Done” and answers questions from attendees about the Increment. This is the part of the Sprint Review that tends to get the most focus. Even if the Product Owner has seen work in-progress throughout the Sprint, it’s likely that other people, including stakeholders, have not. Importantly, this is an opportunity to see the whole Increment to then elicit feedback on what to do next.
  • The Product Owner discusses the Product Backlog as it stands. They forecast likely target and delivery dates based on progress to date if needed.
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning. This includes stakeholders, and potentially even real users.
  • Review the market, changes to stakeholder and user needs, or potential use of the product. Things  might have changed, so the Sprint Review is an opportunity to discuss what’s the most valuable thing to do next based on what has gone on over the course of the Sprint.

Demonstrating the Increment

It’s easy for software teams to demonstrate that their Increment of working software is robust, of high quality, and meets the Definition of Done. Not all Scrum Teams, though, work with software.
  • Data teams, such as those who data analytics and research, do a walk-thru of their reports and data visualisations.
  • HR teams go through the results of their metrics and how the changes they’ve made to the employee experience has created a positive impact.
  • Digital marketing teams show a brief overview of their social media activities and the engagement stats in this last Sprint compared to the previous Sprint and examine trends.
  • Leadership teams review the changes to the system of work they’ve made and review the impacts and outcomes the improvements have made, whether a decrease in lead time to market, an improved ability to pivot to change, or the outcome of red tape reduced.

Whatever way the Team chooses to demonstrate its work, it’s always done in such a way as to elicit feedback so that the Product Owner can decide on what to do next and where to spend budget.

Don’t forget to review the budget and timelines

The Product Owner is responsible for release timelines, budget, and stakeholder engagement. The Sprint Review provides them with the opportunity to get feedback from stakeholders to then decide whether to adjust future releases, invest more money in specific areas of their product, or pivot to changing needs. Importantly, this means that the Scrum Master isn’t a Release Manager, responsible for the release of the product, and there is no Project Manager who manages the budget on behalf of a project board. Because Scrum is an agile product development framework, all of these responsibilities lie with the Product Owner.

 

Download Sprint Review Checklist

About the author

Related Posts:

Better together: Agile + Lean UX

How do you make Design Thinking, Lean UX, and Agile work together. Sprint 0? Design Sprints? Upfront design and planning tends to delay the delivery of value, so there must be a better way to use Scrum but also engage in discovery work at the same time without devolving into parallel design work. Integrating design, user research, and experimentation into Sprints is the key.

READ MORE

How do I run a Daily Scrum?

Many people use the Daily Scrum to provide a status report to the Product Owner or Scrum Master, and even to stakeholders, but this event plays a more critical part in ensuring that the team continues to stay focussed on their goal and adapt their work so they improve their chance of achieving it.

READ MORE

How do I run Sprint Planning?

Sprint Planning is one of Scrum’s five events. There’s more to it than just making a plan. Importantly, as an action of empiricism, the team should be inspecting the Product Backlog and adapting, and creating, a Sprint Backlog that makes their plan to achieve the Sprint Goal, and deliver a potentially releasable Increment, transparent.

READ MORE

Setting up a New Agile Team

When setting up new agile teams we have found that starting small with the basics and adding patterns as they start to develop capability has helped us get new teams up and running within 2-3 days and acheive a baseline of agile capability within 3 months

READ MORE
search previous next tag category expand menu location phone mail time cart zoom edit close