In a former article about the sprint review I pointed out that the sprint review is a meeting primarily for the benefit of the stakeholders. Yet, over the years I have visited with companies whose stakeholders are often absent at the very meetings where they should play an integral role!
This blog post is the first in a series of three posting where I discuss eight of the reasons why stakeholders fail to attend sprint reviews and I offer suggestions for how to handle each cause.
Before we get to these reasons and suggestions, though, let’s quickly review the description and purpose of the sprint review.
Quick Overview of Sprint Review
The sprint review is a meeting that gives everyone with input to the product development effort an opportunity to inspect and adapt what has been built so far. The sprint review provides a transparent look at the current state of the product, including any inconvenient truths. The review meeting is the time to ask questions, make observations or suggestions, and have discussions about how to best move forward given current realities. (Read Chapter 21 of Essential Scrum for a detailed description of the sprint review activity.)
Now that we have established this baseline, let’s have a look at two of the eight reasons why stakeholders often fail to attend the sprint review: Nothing to See and Too Technical.
Nothing to See
From my observations, the most common reason that stakeholders don’t attend sprint review meetings is because the stakeholders believe there is nothing valuable to see and discuss. The purpose of the review is to inspect and adapt the product. In the absence of something of stakeholder value, stakeholders will view the sprint review as a waste of their time.
Why would a Scrum team have nothing valuable to review? Perhaps the team did not complete the customer-valuable increment of work it committed to at the sprint planning meeting. Sadly, this is quite common with teams that are new to Scrum or that have not improved their implementation of Scrum to a sufficiently robust level. The solution in these cases is to improve the Scrum team’s overall application of Scrum.
Why else might there be nothing valuable? Perhaps in the current sprint the team worked on a subset of a larger workflow that the stakeholders don’t view as valuable on its own. In other words, the stakeholders only want to review the full workflow and not the incremental pieces of the workflow as they are developed each sprint.
Are the stakeholders right to make such a request? It depends. If the problem is only one of perception—the increment is valuable but the stakeholders don’t view it as such—then the solution is to help the stakeholders understand the economic value of getting fast feedback for each increment. If the problem is that there truly is no value in reviewing a partial workflow (less likely than most people think, but possible), then don’t waste your stakeholders’ time. Invite them to the sprint review only when the completed workflow is available.
Reviews Are Too Technical
A second reason business stakeholders don’t attend sprint reviews is because the sprint reviews are too technical. This is really a special case of the “Nothing to See” reason. If a businessperson attends a review where the discussion surrounds the implementation of a low-level service that no businessperson would ever see or use, you can understand why she would consider this meeting a waste of her time.
Let’s do a bit of root cause analysis here. If the review is focusing only on technical work with no perceived customer value, then it is very likely the team is a component team and not a feature team (see blog post Distinguishing Between Feature and Component Teams for a description of these two types of teams). Since many organizations heavily favor the use of component teams—usually to their significant economic detriment—it might be worth revisiting how the organization has chosen to create its teams.
Feature team sprint reviews don’t usually focus on reviewing technical work, unless there was a need to perform technical work (e.g., spike, prototype, proof-of-concept, experiment, etc.) to buy information (see blog Demystifying Product Backlog Concepts). So, if it makes economic sense, consider restructuring the teams so that most are feature teams, thus alleviating the problem that most reviews are too technical.
If we determine that a component team is warranted, then the problem might be that we have invited the wrong stakeholders to the sprint review. Business-focused stakeholders are not the proper participants in a component-team sprint review. Representatives of other teams that consume the component / service being created by the component team would be the proper stakeholders. And, since these would be technical people, it is unlikely that the sprint reviews would be deemed too technical.
Conclusion
In this blog I have discussed two of the eight different reasons why I have seen stakeholders not show up at sprint review meetings: Nothing to See and Too Technical. For both reasons I discussed why I think the issue is occurring and how and whether I think the issue should be addressed. Are either of these two issues plaguing your sprint reviews? Please leave your comments below!
In the second posting in this series I focus on three additional reasons why I have seen stakeholders not show up at sprint review meetings. I categorize these three reasons under the umbrella of “Too This and Too That.”