To uncover the true potential of the Sprint Review, let’s start with assessing why it exists:
“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.” — Scum Guide 2017
Many read this quote as:
“We show what we have created during the Sprint and gather feedback from our stakeholders about it”.
But this is not what the quote states. Let’s unpack this a bit more and see what an Increment really is:
“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” — Scrum Guide 2017
Many believe the Increment is only the sum of all the Product Backlog Items completed in the Sprint. But that is not the case. The Increment is all existing features plus the new functionality you added during the Sprint. It is the whole product, including what is new. It is the new product update to be released whenever the Product Owner wishes to do so.
When you realize this, you will not limit the discussions to what the team did in the last Sprint. With that, it makes the Sprint Review interesting for a larger audience.
New insights to the product can come from all kinds of places, not only from a demo during the Sprint Review.
Here are some examples of what I mean:
- The team repaired errors in the displayed calculations. Only a small part of your target audience will be interested in seeing this. If your Sprint Review focuses on this only, it falls short on what it could establish.
- The work from the Sprint can have an impact on other — already released — functionality. This without you realising. By demoing and discussing the complete product Increment you can uncover this. Stakeholders may have insights into the impact you never realised before.
- A stakeholder wants to discuss functionality created a few Sprints ago. They recently received positive customer feedback about it. This may be important to further uncover and exploit.
- A stakeholder wishes to discuss functionality created a few Sprint ago. Only now it turns out to be faulty.
- There are new market developments and the product needs to be able to cope with them. A new payment method is becoming very popular and your product needs to be able to use this method to stay relevant.
At the Sprint Review, discuss everything new about the complete product Increment.
In a complex environment, it is important to factor in all new information. It can all impact the decisions on what to do next. Scrum Teams work in complex environments. When you get a good sense of how the increment is working and respond to new information in a Sprint Review, you are adopting the best available tactic in this kind of environment.
“What has happened should be used for forward-looking decision-making.” — me, slightly adjusting a quote from the Scrum Guide 2017
When you ensure the discussions tackle the complete product Increment you allow for strategic product decisions. As a result, the Sprint Review becomes important for senior stakeholders too. The Sprint Review turns into the Steering Committee for the product.
I worked as a Scrum Master for many teams over the years. I have identified two lessons with true stakeholder involvement at the Sprint Review:
Lesson 1: Discuss the complete product Increment. This increases the chances of getting important stakeholders to join the event as they can bring meaningful insights to the table.
Lesson 2: Ensure your essential stakeholders attend the Sprint Review. Allow them to discuss the complete Increment. It will turn the Sprint Review into the event where major product decisions happen. These product decisions impact the Product Backlog.
Both lessons strengthen each other!
Below are three real-life cases to clarify the lessons.
Example 1 — Discuss the complete increment
We made sure to discuss the complete product Increment all the time. At first, only the Scrum Teams and a portion of the stakeholders participated. But soon word spread how impactful the discussions about the product were. Then more stakeholders joined. This included people that were several layers higher in the organisation and people that used the product daily. The Sprint Review made a separate product roadmap meeting redundant. All potential participants for such a meeting were in the Sprint Review already. Decisions didn’t need another discussion.
Example 2 — Essential stakeholders attend the Sprint Review
Another team built a fraud detection product from the ground up. Right from Sprint 1 all essential stakeholders — including the users and directors — were involved in the Sprint Review. We looked at what the team built during the Sprint, new ideas and the actual usage of the product until now. We did not limit the discussion to only include work completed during the most recent Sprint. The Sprint Review was where we had everyone in the discussion. Based on the Sprint Review results, we always could work on what mattered most. The financial regulators of the Netherlands considered our fraud detection product to be best in class.
Example 3 — Failing to keep the momentum
A third team started their journey well. They had a daunting objective. They needed to create a new product using promising but unproven technology. The first Sprint was all about showing they could create such a product. So they built a rudimentary MVP. They succeeded to do so and the Sprint Review was a major success. But after this, the team went on to only demo the new functionality. More and more stakeholders skipped the event. They weren’t interested in these updates and missed the big picture. After a few Sprints, the team hardly got something useful from the Sprint Review.
I love the Scrum Patterns. They are a set of best practices that help explain the rationale behind Scrum. Whenever I stumble upon something new for me as a Scrum Master, I tend to inspect the Scrum Patterns for more insights. I failed to find this for my experiences about the Sprint Review. But, I found a snippet that appears to contradict what I experienced:
“Many Scrum adherents view the Sprint Review as the main mechanism of agile feedback in Scrum, bringing to mind the usual forces of emergent requirements and market changes, change in business conditions, and so forth. There may be a bit of that. But a Product Owner and other stakeholders are unlikely to always be able to assess, in a three-hour meeting (isn’t it 4? — WJA), whether a complex product increment really does meet the intended need or not. More realistic and honest insight comes from trying to use the product in a more realistic application setting, over a more protracted period of time.” — A Scrum Book, Sprint Review
I agree that you can’t assess everything about the product in the timespan of a Sprint Review. But the most time-consuming parts (building the product Increment, gathering feedback from product usage) happen before the event. The Sprint Review is the place to share this feedback and then discuss insights based upon the observations. I argue that there’s plenty of time to do this at this event.
The Sprint Review is the place to provide feedback on insights from also trying the product over a protracted period of time. If the Sprint Review isn’t, there needs to be another meeting. I believe this would be unwise:
“Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.” — Scrum Guide 2017
In a complex product environment, you base decisions on what you know. Even though you only have fragmented knowledge. Sometimes information about a certain change only arrives 3 months later. Don’t let it stop you from bringing it up at the Sprint Review.
There shouldn’t be any ‘we already passed this stage’ mentality. That is traditional waterfall thinking.
Scrum Teams work empirically. This means we learn from new information, and use it to influence ideas about next steps. Regardless where it comes from.
A Sprint Review can last 4 hours. Often though, the event is way shorter as it is a demo only. Perhaps, the team gathers some feedback about this demo. Teams that do it like this waste an opportunity to gain the latest insights on the product. They fail to have the best possible view on what to do next.
Shift the focus from output to outcomes. The Sprint produces an output, the outcome may come later. By shifting focus you can discuss the actual impact of your product.
- Discuss the complete product Increment. Include the new learnings from the functionality you built and shipped earlier. It will allow stakeholders to bring information about the product to the table. Topics like actual usage or user experience.
- Have essential stakeholders at the Sprint Review. Allow them to discuss new learnings about the complete product Increment. The Sprint Review could then make other strategic product meetings obsolete.
These two practices strengthen each other.
These lessons may impact the way you facilitate the event. You may divide the event into slots to allow people to attend the parts they wish to be at. Who says everyone needs to be there for the whole four hours? Having said this, the best decisions come with all the stakeholders together. But, there are options. There’s no one good way.