Tips for the Best Scrum Ceremonies Ever: Sprint Review

What is a Sprint Review?

In Scrum, each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software.

So, at the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum team shows what they accomplished during the sprint. Typically, this takes the form of a demo of the new features.

The sprint review meeting is intentionally kept very informal — a team review of the completed stories from the sprint and a look ahead to the next sprint. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.

Participants in the sprint review typically include the product owner, the Scrum team, the ScrumMaster, management, customers and developers from other projects.

During the sprint review, the project is assessed against the sprint goal determined during the sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it’s more important that they achieve the overall goal of the sprint.

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

Product Owner:

• 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).

Bringing it all together

Remember, the purpose of the sprint review is to showcase your potentially shippable product, or minimum viable product to the stakeholders and make your scrum team look like superstars!

Stay tuned for my last post in this series for tips about the Retrospective. For more great posts like mine please follow #leapFrogSystems.

Robin Morgan is a LeapFrog Systems Agile Player / Coach with over 15 years of experience leading successful teams and projects.