- The Sprint Review with Little Stakeholder Participation
- The Sprint Review Where Nothing Is Done
- Keys to Facilitating an Effective Sprint Review
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Sprint Review Where Nothing Is Done
Team Strike Force has been working hard over the last Sprint and the whole team is feeling under pressure. Team members collectively feel progress is being made, and they know that they are learning a lot—about Scrum, working with each other, their product, the users of their product, and the expectations of their stakeholders. However, they have a sense of trepidation as they gather for their latest Sprint Review. They had a few challenges this Sprint and don’t quite have a Done Increment.
Agnes, one of the Strike Force Developers, leads the way into the meeting room ahead of the rest of the team. The main stakeholders for their product—Gem, the company’s Chief Operating Officer and Daria, the Chief Finance Officer are already in the room.
Agnes sets up her laptop while Darren, one of the other Developers on the team, briefly welcomes the attendees.
“Agnes, are you ready to show what we’ve been working on?” Darren asks nervously.
“Yes,” says Agnes. Before anyone says anything else, Agnes runs through a presentation, showing the results in the user interface of the work-in-progress application. “As you can see, it is working, but we’ve only verified it in Internet Explorer. We didn’t have access to the range of mobile devices we wanted to test on. And our machines are locked from using any other browser.”
“And, unfortunately, we didn’t have time to run stress tests to be sure that the site will still be stable with the new feature with our usual volume of visitors,” Darren adds.
“Okay,” says Daria. “It looks fine, though. So I’m happy to sign this off.”
“Me too. Go ahead and release it!” says Gem.
“Hold on,” says Matt, the team’s Scrum Master. “The Sprint Review is not a stage gate and—”
Gem cuts him off. “So this will be in production by the end of today? This Scrum thing is great!”
“Well,” says Agnes, “I just want to make it clear again that we only tested in Internet Explorer and we didn’t run any stress tests. We need to finish all this testing for us to consider the work Done.”
“But you did test it?” asks Daria.
“Yes, but that was only functional testing on Internet Explorer to see if it worked. It is not really Done.”
“It looks done to me!” says Gem.
Darren chimes in, “We won’t be comfortable releasing it until we have finished all our testing.”
“I’m sure it will be fine!” says Daria. “Scrum is all about taking risks, right? Just catch up with the testing in the next Sprint. We want this in production by the end of today.”
The members of team Strike Force feel overwhelmed and stay quiet.
Helping Stakeholders Understand the Purpose of the Sprint Review
To avoid confusion and uncomfortable situations, the overall guidance from Scrum is not to show work at the Sprint Review that is not Done. We saw in the story that Team Strike Force was pressured to release an Increment that was not Done. Scrum is not about taking risks as Daria stated, but quite the opposite. It is about managing and controlling risks. Undone work should not be released because of the risks involved: poor quality, the potential impact on users and customers, and loss of transparency on the actual progress being made.
Some education may be needed for stakeholders of Scrum Teams to understand Scrum, and good facilitation of the Sprint Review can go a long way. To make it a more valuable event, the Scrum Team should garner feedback on the latest Done work and focus stakeholder attention on value, challenges, and risks. When the Scrum Team is transparent about its challenges, it may even discover that some of its stakeholders can help mitigate risks and remove impediments.
Many Scrum Teams or their stakeholders do not want to spend time discussing the team’s challenges. But in avoiding such conversations, the fundamental issues that prevent real progress from being made are not transparent, storing up problems for the future. Undone work accumulates, quality drops, trust erodes, and stakeholders and customers become unhappy.
Try This! Stakeholder Collaboration over Stakeholder Attendance
Stage gates, milestones, and progress reports are traditional management tools used to demonstrate the progress being made and the current state of affairs. In the absence of any of these in Scrum, companies often revert to using the Sprint Review as a mechanism to fill the gaps. When stakeholders approach the Sprint Review with this traditional mindset, a Scrum Master has a teaching opportunity with them about the framework and empiricism. Until then, a facilitator must guide conversations back to what really matters during the Sprint Review: Done, value, feedback, risks and adaptation. The conversation may feel uncomfortable. The following ideas can help.
Transparency of Done and Undone
Many Scrum Teams are tempted to show and discuss partly completed work in the Sprint Review for different reasons, such as to get feedback on what has been completed so far or just to show that they have been working. However, when a team shows incomplete work, they risk confusing stakeholders about the true progress being made. Scrum is clear about the importance of being transparent about what is Done and what is not.
Our guidance is to simply state the Sprint Goal and the forecasted Product Backlog items for the Sprint at the start of the Sprint Review and make it clear which ones were Done and will be inspected as part of the product Increment and which ones were not.
We always recommend that teams keep stakeholders engaged during the Sprint. Remember that the Sprint Review is the one prescribed opportunity for a Scrum Team to meet with its stakeholders, but this does not preclude interactions during the Sprint that could include showing progress of work and getting feedback as the development work progresses.
Whoever is facilitating the Sprint Review should make clear that only those items that meet the Definition of Done will be formally inspected, and the Sprint Review is the opportunity and invitation for stakeholders to give feedback and influence the adaptation of the Product Backlog.
Make Challenges Transparent
When long-standing systemic issues beyond the Scrum Team’s control prevent them from delivering valuable work, the Sprint Review can be a good place to make these transparent. A facilitated discussion can help everyone understand the problems and the risks involved, and a Scrum Team may even be able to get help from influential stakeholders to resolve impediments.
During the Sprint Review, set some time aside to facilitate a timeboxed discussion between the Scrum Team and stakeholders about which work was not completed and why. This is important information to share and learn from for the future.
One way to do this is to write down on a separate sticky note or card each challenge that the team ran into when trying to complete the work of the Sprint that is still left unsolved. These can then be posted on a physical or virtual board for everyone to see. These should be long-standing challenges that the Scrum Team identifies and cannot deal with itself, with a risk that they will prohibit future work from being completed.
By making these systemic challenges transparent, and specifically at the Sprint Review, help or a solution could be offered by one or more of the stakeholders to resolve the issues. For example, in the case of Team Strike Force, one of the stakeholders might happen to be the head of procurement. The stakeholder might be keen to see a particular feature Done that would help their procurement team make better deals with its suppliers; in that case, they may do what they can to influence the process to get the team mobile devices to test on. Or someone from security might be able to do something about the access restrictions to other browsers on the Developers’ machines.
Risks and Their Impact on Longer-Term Forecasts
At the Sprint Review, a perfectly valid conversation between the team and stakeholders is around long-term planning. Typically, internal and external stakeholders want to have some idea of what the future looks like, however uncertain. In the Sprint Review, the Scrum Team resets stakeholder expectations based on new learning. Adjustments to the Product Backlog and future plans can be made in collaboration with the stakeholders, with the latest understanding of how the Scrum Team is progressing.
Some may consider such long-term thinking as inherently anti-agile. However, a Scrum Team needs to have direction so that it aligns with strategic goals, and this is provided by the Product Goal in Scrum. A path to chaos is disregarding what the future might hold and failing to monitor the progress toward a strategic goal. Therefore, we believe it is important to share the latest updated forecasts for transparency, consideration of progress toward the Product Goal, and as a conversation starter.
Many times, the conversation stops at the point of a forecast being produced. However, from an Agile perspective, this is where the conversation should begin. The forecast can be used to facilitate a conversation with prompting questions such as these:
Where are the risks and impediments that might cause the forecast to be wrong?
What are the implications if the forecast is wrong?
This mindset helps to shift thinking from adherence to a plan to driving improvement.