The last day of the sprint, finally! This week’s sprint was particularly challenging, and our team is ready for the sprint review. Like clockwork, we hold our sprint review at the same time and the same place. Depending on what we’re working on, the audience may change, but the review is a consistent part of what makes our team great. Collaboration with our stakeholders is our secret sauce.
The anatomy of a sprint review
We earned our stakeholder’s trust and confidence because we act on their feedback, speak their language, and work hard (and play hard, too). They don’t hold back, though, and we don’t take offense. Their feedback informs our product backlog, and we consider their ideas thoroughly. We learned to make our reviews an informal but extremely valuable conversation about the product’s features that matter most.
After our daily scrum, we briefly discussed how we would present the sprint review and who would do which part. We rotate these assignments so everyone gets a chance to develop their presentation skills. Our conversations include things important to stakeholders. We speak in business terms and avoid getting too technical. Everyone agreed to show up early to ensure the demo equipment or virtual meeting sharing will work well.
During planning, we made sure not to overcommit our sprint, which allowed us to learn and adapt. The product increment we’ll demonstrate fulfills our definition of done, including updates to automated tests, updated documentation, and even security vulnerability scanning.
We tested the latest product increment in an integrated, production-like environment. Everything is ready to be put into our users’ hands when our product owner says, “Go!” It’s nice walking into a sprint review, having confidence in the quality of our product, and our stakeholders have more certainty in our quality, as well.
Holding the sprint review
The review begins with a brief welcome and introduction by our product owner on the sprint goal and the team’s accomplishment. She walks to the whiteboard as our amazing development team begins the demonstration so that she can capture feedback in real-time. The development team demonstrates the product increment. They review the stories’ intent and acceptance criteria, then show how the product meets the requirements.
They frequently pause for questions and to hear stakeholders’ ideas. As the demo wraps up, the product owner asks, “Based on everything we’ve seen to date, and looking at our remaining product backlog and considering the feedback from today, what do we think should be addressed next?” seeking everyone’s perspective.
She makes sure the remaining budget and updated timeline are transparent during this conversation. The stakeholders share many ideas about the priorities but know the product owner can make the best decision for the product and organization. She’ll change her product backlog as necessary.
The entire review takes about one hour since we hold weekly sprints, using the time effectively because we have little interaction with stakeholders. We leave the review energized and ready for our team’s sprint retrospective. Our stakeholders’ appreciation is motivating, but not as motivating as the value our product will create for our customers.
What is a sprint review?
According to the 2017 Scrum Guide:
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. 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.
Sprint reviews are informal, open, and collaborative conversations with stakeholders about what the team completed in the sprint.
A typical agenda format for sprint review is:
- Review the sprint goal and the scrum team’s accomplishments (product owner).
- Demonstrate the product increment for feedback (development team presents while the product owner gathers input).
- Collaborate with stakeholders and the scrum team on the next things to optimize value (product owner).
Time box: one hour per week of sprint length (if the sprint is two weeks, then the sprint review is time-boxed for two hours, etc.)
The sprint review audience is the scrum team, stakeholders, agile mentor, and, if possible, customers. Customers add a different, healthy dynamic to the sprint review, motivating the team and stakeholders. To hear a customer say, “Wow! That feature is awesome!” spreads encouragement.
Team roles
The product owner owns the sprint review. While the sprint review is open to everyone, they personally invite stakeholders whom they believe will provide the most value. Product owners kick off the review and capture feedback. At the end, they share the upcoming priorities, budget, and timeline information. Their most important responsibility, however, is to listen and observe stakeholder reactions during the review.
The development team is next on the stage. They demonstrate the product increment seeking feedback. The team avoids becoming defensive and actively engage the stakeholders in conversation and collaboration.
Sprint reviews are like the Olympics to the development team. World records are most often set during the Olympics. Why? With millions of people watching, it’s the largest stage in sports, where athletes rise to the challenge. Development teams do the same during a sprint review. The sprint review is their opportunity to shine. Let them shine!
The scrum master ensures that the environment enables the team to be successful. They make sure the room is ready with enough chairs. They post information radiators such as the product vision statement, the product roadmap, product backlog, release, and sprint goals, and maybe even the definition of done. They teach everyone about the purpose of the sprint review and the ground rules, helping the team stay within the allotted time box.
What are the keys for an effective sprint review?
Establish Ground Rules (aka a Sprint Review Working Agreement)
Ground rules help everyone understand the sprint review expectations. Examples could include:
Be where you are. Avoid distractions, such as mobile phones or email.
- Speak up. The only way we’ll know what you’re thinking is if you say it. All ideas welcome!
- Refrain from pageantry; it’s the enemy of agility.
- Avoid calling sprint reviews sprint demos. Calling it a sprint demo short-changes the collaborative perspectives of looking back and forward.
- Show only “done” (shippable) stories and product increments. Set expectations with stakeholders that what they’re seeing can be immediately made available to the customers.
- Demonstrate the shippable product increment in an environment that reflects how customers will use it.
- Rotate demonstration responsibilities amongst developers. Give everyone a chance to be on the stage.
Create an informal conversation environment
The best sprint reviews are informal conversations with stakeholders. Stakeholders need to feel safe that they can express ideas or concerns without recourse. Keys for making a sprint review informal are:
Minimal prep time: The scrum team should plan to spend no more than 20 minutes preparing. Make the conversation a natural extension of the team’s sprint.
- No PowerPoint slides: Time is better spent on building valuable working product increments than creating presentations. Don’t tell us, show us!
- No rigged demos: Rigged demos are like lies. They create more work for you in the next sprint. They’ll bury you.
- Practicing openness and courage: Help everyone feel comfortable attending your sprint review and expressing their truthful opinions courageously. Your product increment has the potential to better align with the needs of the customer, and you need to know it.
- Letting the stakeholders interact with your product increment: Think of what you could learn by watching people unfamiliar with the product increment interact with it! Let them test drive your product.
Adapt for multiple teams
Organizations often have multiple teams working together on the same release goal. In these cases, adaptations may be necessary to accommodate numerous sprint reviews occurring simultaneously, especially if the stakeholders are the same. Some ideas that may help:
Combine sprint reviews. Allow stakeholders and team members to see the entire product increment holistically. This approach may require careful coordination among the various teams to stay within an acceptable time box. Consider using the bazaar or science fair format.
- Use the bazaar or science fair format, encouraged in Large-Scale Scrum (LeSS), holding the sprint review in a large room or via multiple virtual channels. Stakeholders can move from station to station (or virtual channel to virtual channel) at their leisure to see your product increment. An intimate stakeholder conversation about your product can be very beneficial.
- Ask for feedback. Learn from stakeholders about their preferences. Do what makes the most sense for your situation. Periodically discuss ideas and experiments for improving your sprint review during sprint retrospectives.
- Align sprint cadence for all teams to start and end the sprint together. Let the sprint review inform the sprint planning decisions of all the scrum teams involved in the release.
- Self-organize to maximize value for all in the reviews. Each team may need to send a team member to represent them at another team’s sprint review. Be creative.
Effective sprint reviews final thoughts
The most important outcome from the sprint review is an updated product backlog. New, more valuable ideas may arise from the sprint review, so have the courage to modify priorities based on what you learn. Better yet, use your sprint review to discover if you reached the point of diminishing returns. If you’ve hit this point, then it’s time to consider moving on and redeploying capital to the next most valuable priority.
Holding an effective sprint review should be a crucial part of the product development process. The keys are establishing healthy ground rules, keeping them informal, and setting accurate expectations (no lying!). Not only share the product but also exhibit the team’s personality, challenges, and uniqueness – be transparent.
Need guidance on effective sprint reviews? We can help. Contact us today.
