What is a Sprint Review?
Agenda for a Sprint Review
Product Owner identifies what has been done and what has not been done
Development Team talks about the Sprint:
What went well
Problems that arose
How they solved those problems
Demonstrates completed work/Product Backlog Items
Answers any questions
discusses current snapshot of Product Backlog and Roadmap
projects likely completion dates with various completion rate (or velocity) assumptions
All attendees then discuss previous agenda items and how they affect what to do next.
The Sprint Review also provides vital input into the impending Sprint Planning Meeting.
Tips for a Good Sprint Review
It is not a best practice to use the Sprint Review as a signoff or user acceptance meeting
Make the demo an informal one, maybe even done on a developer’s machine, but make sure that it is visible by all at the meeting (project it onto a big screen if need be)
Spend no more than 1 person hour preparing for the demo
Remember that a Sprint Review is much more than just a demo, also review the upcoming sprint and the results of the previous sprint on the overall release plan and product roadmap.
Time-box it to 1 hour per week of Sprint length (i.e. 2 week sprint = 2 hours, 4 week sprint = 4 hours, and so on)
Different teams will have differing needs as far as how much detail to go into during the Sprint Review. Tune your approach according to the needs of the attendees.
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 necessary to clarify Scrum roles, rules, or principles.
Treat all feedback as welcome feedback, especially from stakeholders
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 never 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
Make sure the right stakeholders are present. Generally speaking this is a responsibility of the Product Owner (Provides vision) and the ScrumMaster (Resolves impediments).
Author = Robin Morgan (LeapFrog Systems via Medium)