A deeper understanding of…
The Sprint Review
Road to PSM III — Episode 19
🥅 Purpose.
The Sprint Review serves to optimize value and to create transparency between the Scrum Team and stakeholders over the Product Backlog and the Product Increment.
The purpose of the Sprint Review isn’t to provide a status update or a presentation to stakeholders. It is to collect and process feedback on the actual Increment.
“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
The goal of the Sprint Review is to inspect the Increment…
and adapt the Product Backlog if needed to optimize value.
“Attendees collaborate on the next things that could be done to optimize value” — The Scrum Guide
🤔 Who?
The entire Scrum Team and key stakeholders invited by the Product Owner.
For this collaboration to work well, we have to focus first on Scrum’s values. Stakeholders too should be aware of upholding Scrum’s values during this event.
“The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.” -The Scrum Guide [emphasis added]
The Scrum Master will help the stakeholders understand the concept and value of iterative development. This includes the concept of early involvement and the continuous nature of inspection and adaptation. During the Review the Scrum Master is
“Helping employees and stakeholders understand and enact Scrum and empirical product development;” — The Scrum Guide
In traditional environments stakeholders may not be used to the true emerging nature of product development. Stakeholders at first might not understand how they are a valuable contributors (if not essential) to development. A Scrum Master will help them understand it will likely take a development team few iterations before they hit the mark.
The collaboration between the team and stakeholders will help them hit the mark sooner rather than later which reduces waste in the process.
They’ll also learn that the better the stakeholders and development team understand each other and become aligned, the quality of each increment will increase. They’ll come to value discovering improvements, impediments and misunderstandings early.
Participation
Stakeholder attendance could be a challenge for a Scrum Team. Key stakeholders might argue they don’t have time to attend each Sprint Review. They might ask for a status update or meeting notes to be mailed to them. It is indeed not essential for all stakeholders to participate or attend each Sprint Review. The Product Owner will invite key stakeholders relevant to the Sprint or the next.
Stakeholders will come to value this event as this is the most influential moment to get their interests represented.
At times a Scrum Team might argue not all its members would need to be present as it would do to just have a few individuals provide the demo or collect feedback. They clearly have not yet grasped Scrum’s fundamentals. It’s an opportunity for all to inspect and adapt and to develop transparency. As without this… I’ll repeat … ➰➰
decisions will be flawed, progress will not be predictable, risk is not controlled, conflict occurs and value goes down the drain!
🗓 When?
A Sprint Review is held at the end of the Sprint prior to the Sprint Retrospective.
It is not uncommon for Scrum Team members to argue the Sprint Review should be postponed. Reasons (excuses) could be that:
- The Sprint Goal is not yet achieved;
- The forecasted PBI’s are not yet “done”;
- The Increment isn’t in a reviewable/presentable state;
- Some key stakeholders, developers or the Product Owner could not (or would not) attend;
These aren’t prerequisites to the Sprint Review. In fact, they are all the more reason to proceed with it. Remember, this Sprint Review serves to benefit transparency and this requires participants to be open about all the challenges too. Even when the team knows some of this transparency is already lost due to the increment not being reviewable or key participants not joining. It becomes all the more important to inspect, even if the inspection itself is challenged. It is an essential learning opportunity. Don’t shy away from inspecting something together, even if you already know you are reviewing something that isn’t in a desirable state.
Remember too, there will be additional reviews down the line with each Sprint, so whatever you weren’t able to do now, do it next time. Use this time to get set to kick off the next Sprint.
🕗 How long?
Max. 4 hours for a monthly Sprint. For shorter Sprints, this is usually less. It is not uncommon for teams to reduce the time-box relative to a Sprint’s duration. A one-week Sprint could have a 1-hour time-box.
As a Scrum Master, I personally find this the hardest event to teach participants to stay within the timebox. I learned that teams shouldn’t postpone inspections and review of work, the processing of feedback, and the subsequent backlog refinement to the Sprint Review. They can do this throughout the Sprint. The same goes for inspecting if the Increment meets the Definitions of Done. This can be done during the Sprint, prior to the Sprint Review.
✅ Preparation.
It pays to have the following prepared for the Sprint Review. The Scrum Team self-organizes this, helped by the Scrum Master.
- A refined Product Backlog
- The Sprint Goal (including progress made and known work remaining)
- The latest Product Increment, including verified facilities required to inspect and review it.
- The definitions of “Done”
- Product Backlog items that have been “Done” and what has not been “Done”;
- A log of went well during the Sprint, what challenges the team ran into, and how those challenges were addressed/solved.
- Leanings/inspections from the marketplace.
- Desired projections
- Assessment of progress toward completing projected work by the Product Owner.
- Past performance of the Development Team
- The projected capacity of the Development Team for the next Sprint
🔎 What happens during the Sprint Review
First and foremost, the Scrum Team processes feedback on Product Increment. Not just from stakeholders, but also from its own team members. They collectively discuss these and align on it. The Product Backlog is revised to contain this feedback. Together everyone aligns on what to do and where to go next.
The Scrum Guide is already pretty specific as to what is supposed to happen during a Sprint Review and you could almost run through it like a checklist. So here it is directly quoted from the Scrum Guide with added emphasis.
☑️ 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.
Now Scrum Teams will (or should at least) work towards improving the Sprint Review. It is up to the Scrum Team to make it all worthwhile and discover how it will generate the most valuable feedback and next steps from it. Spice up your review. Learn by attending other Sprint Reviews or check out some awesome examples online like this one:
😤 Disagreement and misalignment
Let’s back up a little. One of the purposes of a Sprint is to create a “Done”, useable, and potentially releasable product Increment. If work on a PBI doesn’t meet similar criteria it will not be included in the Increment as the Increment should always remain in a usable condition. That said, this is not to say that no more work is to be done on PBIs that are considered “done”/“useable”/“potentially releasable”. When the increment is delivered, it can and should be improved as more is learned/discovered from its use. It baffles me that many Scrum Teams are hardly ever revisiting what they consider to be “done/delivered/released”.
Teams (or even organizations as a whole) tend to focus mainly on ‘the new stuff’.
The amount of time spent on it is nowhere near similar to what goes into ‘improvement’. The Sprint Review is a great moment for the Scrum Team to share valuable discoveries made during inspections and propose improvements proactively. How did the previous increment survive contact with the user?
With that in mind, let’s visit a common source of tension between a Development Team, the Product Owner and stakeholders.
I’ve experienced that (in general) stakeholders and even Product Owners have the expectation that something has to be completely done and final by the end of a Sprint. Most commonly so in client/vendor like relationships.
Do they know Scrum is all about incremental development and continuous improvement? Inspect ➰Adapt?!
When during a Sprint Review it is transparent a Sprint Goal isn’t met or not all forecasted PBIs are considered “Done”, this isn’t to say the Development Team didn’t ‘meet its commitment’. This is really where Scrum’s Values come into play once again. The Scrum Team should at least have (reasonably and professionally) demonstrated its resourcefulness, willingness, and pro-activeness to creatively and productively do what they could. This could include involving the Product Owner early, being open about challenges and asking for help, responding to valuable change, and taking on newly discovered complexities head-on, together…as a team. It’s important that the Development Team demonstrates its flexibility, creativity, and productivity and everyone respects their adaptability. How, for example, did Scrum Team members demonstrate courage to do the right thing and work on tough problems? In any case, during a Sprint Review, everyone should respect each other to be capable, independent people. Even when (or especially when) things aren’t apparently swinging.
It is my experience that the second source of tension is about what the Development Team should work on next, or where and how something should fit in the Product Backlog. Stakeholders inexperienced to working with Scrum (Teams) may demand certainties upfront, which they generally won’t get from a Scrum Team as the Scrum Team needs to remain adaptable to newly discovered value and complexity. Stakeholders who are not yet used to continuous planning might still rely on rigid roadmaps where a lot depends on hitting a target date. This is where things might get heated. When there is frequent disappointment during a review, there likely isn’t enough involvement and collaboration throughout the Sprint. The Scrum Team and stakeholders may not be basing their forecasts on past experience. Sharing past projections on the performance of a Development Team will help. There is always some reliability as to what a Development Team will be able to do, even in complex environments; that said, there is equal (if not more) unreliability in play as well.
“Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide
In a weird way, an experienced team in a mature environment will (to an extend) be able to predict its (in)predictability. A team might share the predictability of the delivery of an item based on what is known, taking into consideration potential unknowns. It can base its predictions about where it is ordered in the Product Backlog as is, knowing this could change. At times one has to be realistic and some ideas are just not worth it. Not all PBIs will make it to the product, and some will be removed from it.
A Product Owner too will need to make (at times unpopular) decisions on the order of items in the Product Backlog. The interests of various stakeholders might nog be compatible with what the Development Team is able to deliver based on what is known about their past performance. It is important that the stakeholders respect the Product Owner's authority in this, even when the decision made by the Product Owner isn’t favorable to the stakeholder. As a Product Owner, you just can’t satisfy all stakeholder wishes. (Just make sure you don’t upset them all.)
If this is indeed a challenge for stakeholders and Product Owners in your organisation, you could try out Stakeholder Tycoon, a fun and interactive collaborative game that demonstrates the complexities of Product Ownership and Stakeholder representation.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
Next episode:
