Improve Sprint Reviews with Acceptance Criteria

Let’s treat Scrum Events like Product Backlog Items. A good PBI has a clear Outcome, Who is for, and Acceptance Criteria. 

Outcome: Adapt (modify, change, reorder) the Product Backlog in order to meet the Product Goal. 

Who is it for?: The stakeholders

Acceptance Criteria: 

  • Are we demonstrating usable increments? 
  • Are we getting feedback from the stakeholders? 
  • Are we collaborating with the stakeholders on what to do next? 
  • Did we avoid over-solutioning? 

Outcome: “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.” – The Scrum Guide 

It’s not a status review, it’s not “death by slides, ” it’s not “hey, look how busy we were.” 

What it is, in the living embodiment of Transparency, Inspection, and Adapation. What did we do, what is left to do, how are we doing towards meeting the Product Goal, and what do we need to change to meet the Product Goal? 

Who is it for? The Sprint Review is not for the Product Owner. The PO should run this meeting, send out the invites, set the agenda, and be the first to speak. The audience is your stakeholders. Transparency is a two-way street and if you are not getting feedback from your stakeholders, there is almost no point in doing a Sprint Review. 

Acceptance Criteria: Are we demonstrating usable increments? 

We don’t show slideware. We don’t show partially done work that may change. We show work that has met the Definition of Done. 

Acceptance Criteria: Are we getting feedback from the stakeholders? 

See “Who is it for?” above. Transparency is a two-way street. 

Acceptance Criteria: Are we collaborating with the stakeholders on what to do next? 

Yes, the Product Owner is accountable for the Product Backlog. However, they are not an island or an ivory tower. “The best architectures, requirements, and designs emerge from self-organizing teams” – Principle 11, Agle Manifesto. Collaboration with the stakeholders and developers is the key to a better product. 

Acceptance Criteria: Did we avoid over-solutioning? 

A two-week Sprint Review typically has a timebox of two hours. That goes surprisingly fast if you solve everything in your Product Backlog in that time. Unless you can resolve something in a few minutes, the better use of time is to agree on who needs to be in deeper conversations and schedule those future conversations. 

Making Sprint Reviews better by treating them like a Product Backlog Item. 

This has been a 🦍 Gorilla Coach 🦍 Scrumdementals moment. Have a nice day. 

Leave a Comment

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

Scroll to Top