Sprint Review Tips
These tips are not a part of Scrum according to the Scrum Guide. They are my own personal tips based on my Scrum Coaching experiences. I do believe these tips are consistent with the Scrum Guide.
- First, foremost, and most importantly, know what a Sprint Review is supposed to be. Read the Scrum Guide, it’s only like 20 pages. Specifically, read the section on the Sprint Review and make sure your team is in alignment with the Sprint Review as it is described in the guide.
- It is a worst practice to use the Sprint Review as a signoff or user acceptance meeting.
- Make the demo be an informal one, maybe even done on a developer’s machine.
- Spend no more than 1 person hour preparing for the demo.
- Have your Product Owner play the “lead emcee” role in the Sprint Review.
- Have the ScrumMaster be a silent observer in the Sprint Review. Ok, maybe not a silent observer, but at least a role where they only get involved in the review if it’s absolutely necessary to clarify Scrum roles, rules, or principles.
- Treat all feedback as welcome feedback.
- Treat the Sprint Review as if you were doing a focus group on your just completed features. Be curious about any hint of feedback, and ask for suggestions from everyone (including developers) on how to gain more value from the current and future features.
- Never say “no” outright to a new feature or enhancement request. Always put it on the backlog. It may go way down in priority on the backlog, but put it there. You might word the backlog item slightly differently than the suggester did, but put it there. Try to word it as a request for functionality or request to solve a problem (“the what”)rather than a “do it this way” command(“the how”).
- Any feedback that results in changes to be implemented is a new Product Backlog Item.