This blog post is the third and final in a series of three postings where I discuss eight of the reasons why stakeholders fail to attend sprint reviews and I offer suggestions for how to handle each cause.
In the first posting I focused on two reasons that I categorized as “Nothing to See Here.” Specifically: nothing done for a stakeholder to see, and work that is too technical for business stakeholders to review.
In the second posting I focused on three additional reasons that I categorized as “Too This and Too That.” Specifically: reviews that take too long, stakeholders that are too busy to attend, and time conflicts (too many things scheduled at the same time).
This posting focuses on three additional reasons that I categorize as “Simple Misunderstanding.” Specifically: not being invited, management by exception, and stakeholder feedback available every day.
A sixth reason (the first five are described in the two prior postings in this series) that stakeholders don’t attend the sprint review is that they weren’t invited. This tends to happen when people (the development team, the product owner, or the ScrumMaster) misunderstand whom this meeting is really for. Some might mistakenly believe the meeting is only for the members of the Scrum team, with a principal focus on showing the completed work to the product owner for acceptance or rejection. The sprint review is not for this purpose.
The sprint review is intended for the stakeholders who can’t be involved with the Scrum team day to day.
This meeting gives these stakeholders at least one opportunity each sprint to review and provide constructive feedback to the Scrum team on the product increment. (See blog post It's a Sprint Review, Not a Sprint Demo for more details).
To summarize, stakeholders not showing up because they weren’t invited can be addressed by properly defining the sprint review and who should be in attendance.
Management by Exception
A seventh reason that stakeholders might not attend a sprint review can be traced to an attitude of management by exception. Basically stakeholders take the attitude of I trust you guys to get the job done, and I’m sure you’ll let me know if you have any issues. On the surface this attitude has the appearance of trust and delegation (both admirable) with the intent not to micromanage. To me this attitude is misguided.
Providing timely feedback that leads to inspecting and adapting is not micro-management!
Sprint reviews are an opportunity for people with deep knowledge of the environment in which the product must operate and thrive to show up and leverage that knowledge to the overall benefit of the organization. Waiting for the team to realize “it has issues” might seem like the right thing to do, but the reality is that teams often don’t know they have a problem with the product. Only by getting timely stakeholder feedback can the team inspect and adapt in an economically sensible way to deliver a killer product.
Help stakeholders understand that attending a sprint review should not be viewed as a form of micro-management, but instead as an opportunity to help everyone involved inspect and adapt their way to a solution that delights the users or customers.
We Get Feedback Everyday
The eighth and last reason I will discuss for why stakeholders don’t attend sprint reviews is those same stakeholders provide a continuous stream of feedback to the Scrum team during sprint execution.
What if we worked in an environment where our stakeholders were available to us every day to provide feedback? What if we could ingest that feedback in a way that didn’t violate our “no-goal-altering-changes-during-a-sprint” rule (see Chapter 4 of my Essential Scrum book)? What if we operated in a mode of continuous delivery to our customers? In such a world, you might question why a sprint review is needed at all. Meaning if we could achieve all of the benefits of the sprint review continuously during sprint execution, then maybe we don’t even need a sprint review and thus there would be no issue with stakeholders not attending. I believe this is a valid point.
In my experience, this scenario is becoming increasingly more common and we might see in the future that more teams get the benefits of their sprint review during sprint execution!
In this third and final blog in the Stakeholder Missing from Sprint Reviews series I discussed three more reasons why I have seen stakeholders not show up at sprint review meetings: not being invited, management by exception, and stakeholder feedback available every day.
Part one of this series focused on the two reasons of: nothing to see and too technical.
Part two of this series focused on the three reasons of: reviews that take too long, stakeholders that are too busy to attend, and time conflicts (too many things scheduled at the same time).
So, there you have it! The eight most common reasons I see for stakeholders being missing from the sprint review meeting. What do you think? Please leave your comments below so we can discuss them!