Does Scrum hold up to scrutiny? - The Sprint
Does Scrum hold up to scrutiny? - The Sprint
Chapter 8
I’m on a journey to go through the complete Scrum Guide (2020 version) and turn it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
Then I discussed the Scrum Team. And I wondered how often is it that a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to make effective use of the framework.
The fourth topic was the Developers, who should own the What, How, and When to achieve a Sprint Goal. And the last two weeks I wrote about my issues with the Product Owner and Scrum Master accountabilities and asked if they aren’t too prescriptive.
My next iterations of this journey will discuss the Scrum events. Last week I talked about the purpose of the events. This week, I will tackle the Sprint.
The heartbeat of Scrum
Sprints have a fixed length of a month or less. The fixed length should create consistency. But some critics claim this fixed length is a weakness of Scrum. Because Scrum is a framework for complex product domains. The nature of complex domains is that in every Sprint you address something unknown. This means that you might need one week in one Sprint, but two weeks in the next and 3 days in the third Sprint.
While I do understand the reasoning for these criticisms, I argue that the consistency of the fixed Sprint length brings many benefits. First and foremost, stakeholders know when the Sprint Review takes place, so they will have an easier time ensuring they attend the event. The steady rhythm brings clarity and commitment. So I understand the decision to have fixed-length Sprints.
Secondly, the fixed Sprint length helps Scrum Teams to assess how much they can do during a Sprint. Despite the complexity of the work, they can do a decent assessment to make the Sprint effective.
The Sprint is a month or less. I get why the Scrum Guide still sticks to the maximum length of a month. For some products, it may not be possible to create increments faster than every month. But I like that the Scrum Guide emphasizes the benefits of shorter Sprints as they will allow for more learning cycles and a reduction of risks. It also forces people to collaborate to achieve the Sprint Goal. You can’t simply hand off work from one person to another in a short Sprint.
A new Sprint starts immediately after finishing the previous Sprint. This is logical, because the Sprint is the heartbeat of Scrum, as the Scrum Guide says.
Product Goal and Sprint Goal
I am happy with the formal introduction of the Product Goal in the 2020 Scrum Guide. The Scrum Guide establishes the Product Goal as the north star for the Scrum Team. All work in the Sprint should be a stepping stone toward this Product Goal. I believe it is a good thing that Scrum underlines the importance of looking beyond the Sprint. It helps to bust the myth that Scrum is ignoring longer-term objectives. I will discuss this in more detail in a separate article about the Product Goal.
The Scrum Guide also clarifies how important the Sprint Goal is. It is not about finishing the Product Backlog Items according to planning, No, it is about achieving the outcome as defined in the Sprint Goal. I will discuss this in more detail in a later chapter.
Having said this, I struggle a bit with the sentence “Each Sprint may be considered a short project.” I do understand that this is all about achieving a specified outcome within a Sprint. But the traditional mindset is still so prominent. I have witnessed many misinterpreting this line as referring to the delivery of items instead of achieving a goal. Therefore I would suggest a change to “Each Sprint may be considered a short project to achieve the Sprint Goal.”
Additional practices
It is interesting to see the Scrum Guide 2020 discuss tools that forecast progress, like burn-downs, burn-ups, or cumulative flows. They are quickly mentioned as being potentially useful, but as quickly put aside as never being as important as empiricism.
I wonder why these practices are discussed in the first place. The Scrum Guide trimmed almost all prescriptive elements. Why not remove the quick reference to the above-mentioned tools as well?
This part of the Scrum Guide has one of the best quotable lines:
“In complex environments, what will happen is unknown.”
Followed by:
“Only what has already happened may be used for forward-looking decision making.”
These statements are a perfect expression of the empirical nature of Scrum. Having these in mind when reading the Scrum Guide has been very enlightening for me.
Sprint cancellation
The final words of the Sprint section are about the cancellation of a Sprint. It informs us about two things:
Sprint can only be canceled when the Sprint Goal becomes obsolete. In other words, when it doesn’t make sense to pursue the Sprint Goal (anymore).
The Product Owner is the only person who can cancel a Sprint. This makes sense because the Product Owner should have in mind what makes sense to pursue in order to maximize the value of the product.
I know from experience that many have issues with understanding what ‘obsolete’ means, that it doesn’t mean you should cancel the Sprint when you fail to achieve the Sprint Goal. It may be worthwhile to better explain what obsolete means and what it doesn’t mean.
Final word
I think the section of the Scrum Guide that explains the Sprint is logical and clear. It could help to clarify some of the statements to remove ambiguity. And perhaps the Scrum Guide doesn’t have to discuss possible practices to forecast progress. After all, the Scrum Guide already explicitly stated that other sources may provide patterns, processes, and insights that complement the Scrum framework. So why mention them anyway?
