Sprint Review
The Sprint Review is an event where the Scrum Team and key stakeholders inspect the resulting product Increment at the end of the Sprint, and collaborate to derive what was done and the next items that can be done to “…optimise value…”[3] as an input to the next Sprint Planning event.
During this informal get together, the Development Team demonstrates the work that they have “Done” during the Sprint to elicit feedback and inspection from the other attendees. This may also include any difficulties that the team ran into and how they resolved those impediments.
A review of the timelines, progress towards the goals with respect to the capabilities, and the market reception for the current product and the value it provides may also be reviewed.
Practical Tips
| Inspect & Accept ≠ Inspect & Adapt | A common mistake with the Sprint Reviews is to assume that work is to be demonstrated by the Development Team, which is then accepted by the Product Owner.
A much better way forward to avoid the pressure on the Product Owner and the “blame game” is to focus on a collaborative effort between the Product Owner, the Development Team and the stakeholders to understand what has been “Done” and how the Product Backlog needs to be refined ready for the next Sprint or Sprints. |
| Superficially Done | Avoid superficial “Done” increments that are demonstrated by the Development Team in the development environment, and instead, aim to demonstrate the items in more mature environments such as testing or pre-production to really prove that they have completed things to a reasonable level of “Done”. |
| Key Stakeholders | Key stakeholders that will participate and collaborate with the Scrum Team to inspect and offer good insightful feedback are more important than passive stakeholders who just want to be informed. |
| Flow | Working through items on the Sprint Backlog that are deemed to be “Done” can work as a prompt for demonstrating the work, and works well if the items are discrete and independent of each other.
For related items, using scenarios that incorporate multiple items may have a better flow for the audience to comprehend the demonstration. |
| Orientation | Having a high level diagram of the overall context can help the attendees to orientate themselves and draw attention to where this particular product Increment sits within the larger user experience or feature landscape. |
| Demonstration | The Development team may find some benefit in preparing a demonstration before the review, however, live demonstrations with the stakeholders getting hands on and operating the features often provides more in-depth understanding and insightful feedback. |
| Feedback + Product Backlog Refinement | Feedback from the Sprint Review usually results in Product Backlog Refinement activities to refine existing or incorporate new items as a result of the Sprint Review, and is best done as the discussion takes place rather than waiting. |
| Done | Delivering items to a Definition of Done that is reasonably mature can build a team’s confidence and improve the focus during the Sprint |
| Metrics and Data | Reviewing metrics and the overall release plan can help to put things into perspective especially if the current Sprint results in a change of expectations. Use the data to help refine the Product Backlog and set up the next Sprint to succeed. |
| Summary | Closing with a summary of what was reviewed and the impacts of the review can help to close out the event and re-frame the expectations for the next Sprint |
| Environment | Making the environment comfortable with good seating, snacks and a big projected screen for the demo can make the experience a positive one and fosters an informal gathering. |