Scenario #5: The Developers come to you and say that because the functionality they are working to deliver this Sprint is so large, they will have nothing to inspect at the end of the Sprint. As such, they suggest cancelling the Sprint Review.
What would you do?
Getting to Done is hard, however, if you had to summarise Scrum into one idea, it would be just that, getting ‘work’ Done. Scrum Teams often struggle with it due to a variety of reasons; poor planning (we need to ensure the why, what and how are considered), inconsistent understanding of ‘Ready’ and perhaps even poor transparency on what ‘Done’ looks like.
If the Developers are suggesting that they need to cancel the Sprint Review, there is an underlying cause that we need to get to here. It’s a tricky one to assess and act to improve. Particularly, the self-management of a Scrum Team might suggest that they can, in fact, cancel the Sprint Review. That would be a mistake. A Scrum Master is accountable for creating an environment for self-management to flourish but importantly, that it flourishes within the boundaries of the Scrum framework.
If this was a situation you were in, how would you act?
If you’re interested in my opinion, take a look at the video below.
A written transcript is available at the original publishing link, found at the bottom of this post.