Many people have diverted the initial goal of the sprint review but we must accept that the sprint review is not a demo. It is sometimes important to look at the myths around the Scrum because it may be interesting to analyze the reasons for these myths.
What is the sprint review?
If we look at the source of Scrum, the Scrum Guide (the most up-to-date source), here is how the sprint review is qualified:
“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. “
On this first sentence of the Scrum Guide, it is clear that the idea is based on a “Done” inspection. However, is a list sufficient for stakeholders or even key users (sometimes themselves stakeholders)? Must we present the rendering to improve the exchange between the team and the stakeholders?
«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.»
The Scrum Guide is clear that the Sprint Review aims to elicit reactions such as feedback; key users, stakeholders and sponsors would be best placed to do these feedbacks.
«This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.”
This part of the Scrum Guide is generally well understood by all teams that I meet. However, I still see some teams little mature, extend the time of the sprint review for no major reason: an attempt to solve a problem of cable, demo not prepared, no facilitator, Product Owner who doesn’t control his subject…
The Sprint Review includes the following elements:
- ° Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- ° The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
- ° The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- ° The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
- ° The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
- ° The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- ° Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- ° Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.»
Indeed, contrary to many received ideas, we can talk about items that have not been finished. However in some contexts where the deadline concept is very present, I advise the team to avoid to talk about the unfinished request because they will risk this kind of sentence: “so it will be delivered tomorrow then”.
We announce the problems encountered during the Sprint Review and not during the retrospective; we could explain why the team is late about the product development.
«The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities. »
As indicated in the last sentence, the interest of the review is to recover feedback to improve the product. If you don’t invite your key users, you will greatly diminish the interest of this review.
Conclusion : the sprint review is not a demo!
Indeed, you don’t have to copy methods without thinking; this article only intended to remove some beliefs that I still hear in Scrum teams today as: “The Sprint Demo is an indispensable ceremony defined by Scrum. Guide…”.
The demo is interesting during the print review to have a better visibility of the product; this should not replace the main goal of the sprint review: to see the progress of the product and to recover a maximum of constructive feedbacks.
The Scrum Guide is available online for free in many different languages, if you want to read it.
You can adapt this ceremony but it’s interesting to know the origins of it to better understand the methodology in whole.
keywords: sprint review -sprint review is not a demo
1 Trackback / Pingback