Sprint Review Tips

The fourth Scrum Event is the Sprint Review meeting. Review meetings are time-boxed and are meant to be a platform for the team to demonstrate working software to the stakeholders and receive feedback. From the official Scrum Guide:


A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.


I reached out to our team to get their guidance on how to have a successful and valuable sprint review.

What tips do you have for running a valuable Sprint Review meeting?

Jeff Bubolz

Jeff’s Top five things to do in a Sprint Review

  1. Protect your ability to ship and have a conversation around the potentially releasable Increment.
  2. Let your stakeholders use the done working Increment.
  3. Talk about undone work and any impediments around the undone work.
  4. Talk about the future, this could include product vision, market, forecast, etc.
  5. Welcome feedback and change, add feedback directly in the Product Backlog, and have a conversation around priority.

Jeff’s Top five things NOT to do in a Sprint Review

  1. Do not show undone work.
  2. Do not surprise your Product Owner.
  3. Do not have a presentation, have a conversation.
  4. Do not hide impediments.
  5. Do not commit to adding specific PBIs in the next Sprint.

Duane Raiche


There are three tips I would focus on to have a valuable sprint review meeting. One, to practice it beforehand. You don’t have to spend 8 hours crafting a flawless presentation, but running through what you’re going to show once or twice will ensure your review comes off professionally, and will help prevent you from getting too flustered if anything goes wrong. Two, don’t panic when someone disagrees with a decision you made – instead, defer. Acknowledge their question and make sure they’re heard, but offer to discuss it outside of the review in greater depth. And three, do your best to keep the meeting on track. Many stakeholders might not have as much insight into the day-to-day development that goes on and it’s very easy for a meeting to get off track as they see something unrelated that they want to discuss. This is still valuable feedback which should be recorded and discussed, but it can spiral out of control until the review has gone completely off track, defeating the original purpose of showing what you wanted to review with everyone.


Tom Deitz


Over the years a couple of things have really should out to me:

  • Being clear about what is done and what is not is key.
  • Acknowledge feedback and issues a stakeholder may have with what they are being shown but don’t try to solve the “problem” during the review… that is best saved for another meeting.
  • Focus the demo around the users of the feature you are demoing not the functionality. Demo the software as if you where the user performing a task.
  • Most important – bring donuts, cookies or any other treat with you and you will be a hero.


Erin Koth


What makes a great Sprint Review? Making the Sprint Review a Working Session. Reminding yourselves (and your stakeholders) that the goal is to get feedback and make changes to the Product Backlog as needed. Using powerful questions to generate conversation if it isn’t happening naturally. What does that mean? It means using “Who” and “What” instead of asking binary questions. It means asking a specific person (you could even warn them first) how they might change the new feature you added. It also means turning away from Power Point and into demos (especially the hands on variety).


Do you have any recommendations on how to run a successful sprint review?

Get your project started today

Get in Touch