Does Scrum hold up to scrutiny? - The Sprint Planning
Does Scrum hold up to scrutiny? - The Sprint Planning
Chapter 9
I’m going through the complete Scrum Guide (2020 version) and turning 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 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 last article, from a few months ago, was about the Sprint. I feel it’s time to continue the journey, tackling the Sprint Planning.
The premise of the Sprint Planning
The 2020 Scrum Guide is (famously) vastly different from the previous version. This is especially true for the Sprint Planning section. It used to be quite descriptive, telling what should be done.
I like how the emphasis now is on explaining why Sprint Planning exists, what it should achieve, and the prerequisites required to achieve this. The Sprint Planning should “lay out the work to be performed for the Sprint”, resulting in a plan. This can only happen if:
The entire Scrum Team collaborates — Product Owner, Developers, Scrum Master;
Attendees are prepped to discuss the most important Product Backlog Items (PBIs), implying that the Product Owner ensures everyone is aligned on the PBIs.
The Product Owner can make clear how the PBIs help to move towards the Product Goal.
The Scrum Guide doesn’t tell you what state the PBIs should be in. It could even be the Product Owner only introduces them at the Sprint Planning. As long as the Scrum Team understands this and is fine with this, anything goes. The Scrum Guide highlights the importance of transparency without discussing how to achieve this. Rightly so, as every situation is different and every team works differently. Some need to refine thoroughly in advance, others not.
Finally, the Scrum Guide states people outside of the Scrum Team may also attend the Sprint Planning, however, the Scrum Team decides, and others may give advice. This is in line with the Scrum Guide stating the Scrum Team manages their own work.
The Sprint Planning is timeboxed to be 8 hours for a month Sprint, mentioning it is usually shorter for shorter Sprint. I agree with this proposed length, especially considering the topics that need to be discussed and agreed upon. It is not only selecting PBIs. Scrum Teams need to manage complexity and take into account learnings to find the best way to maximize the product value. This is serious business. And it needs time.
Why — What — How
I believe one of the best changes in the Scrum Guide 2020 is the introduction of Why, What, and How as the three topics of the Sprint Planning. It clearly states what a Sprint Planning is for and what should be achieved. How Scrum Teams do this varies greatly. This is good because every Scrum Team has to deal with their unique challenges in their own way.
Why
As the Product Owner is the one accountable for maximizing the value of the product, it makes sense they propose how the current Sprint could best help to add value. It also is logical that the Developers are the ones who can assess if the proposal makes sense. After all, they will do the work and can best determine what they are capable of.
Together, they will craft the Sprint Goal, which is the commitment for the Sprint. The Scrum Master chips in to ensure the team has an eye on their effectiveness using Scrum.
I have always highlighted the importance of the Sprint Goal. I am very happy with how the 2020 Scrum Guide underlines this. Previous versions of the Scrum Guide indirectly stated the importance of the Sprint Goal. Now it is crystal clear: the Scrum Team commits to achieving the Sprint Goal.
It highlights that the Sprint is a feedback loop. The Scrum Team deals with complex topics. This means they can’t create a detailed plan for the Sprint. But they CAN formulate a goal they wish to achieve and then works towards that goal, the Sprint Goal.
What
This section is short and sweet. But what it made abundantly clear is that the Developers select items from the Product Backlog to work on. The Product Owner doesn’t do this, but helps them, through discussion. This has never been as strongly put before.
Now, there’s no mistake: the Developers determine what PBIs they plan to work on. This is another change I like, as the Developers should be in charge of the plan and doing the work. This directly relates to the section discussing the Developers.
PBIs don’t have to be refined before the Sprint Planning. The 2020 Scrum Guide states they can do this during planning too. In fact, PBIs can be created on the spot, if needed.
Refinement isn’t a separate meeting or event. It can be done in all kinds of ways, including doing it during the Sprint Planning. I think this makes sense. In complex environments, you don’t know what the future brings. Feedback from the Sprint Review may result in new insights and new directions. The Sprint Planning may be the earliest moment to discuss this, resulting in newly created PBIs.
I am also very happy with how the Scrum Guide 2020 states selecting the PBIs helps to forecast what the Developers will do. As the path towards the Sprint Goal may change through new information, the PBIs may also change. The Sprint Goal is the commitment, not finishing the PBIs.
How
After selecting the PBIs, the Developers plan the work to create a Done Increment by the end of the Sprint. This is for the Developers. The Scrum Guide says they may want to decompose the work, but also states that how this is done is up to the Developers. The Product Owner and Scrum Master are not mentioned.
Previous Scrum Guides told us that the Developers should have enough of a plan for the first days of the Sprint (at least). However, this is no longer there. Apparently, the writers of the Scrum Guide found this too prescriptive. I think it would have helped to underline how the plan can change during the Sprint. Therefore I don’t agree they removed it.
The How section ends with describing how the Sprint Goal, selected PBIs, and the plan to deliver the PBIs together are the Sprint Backlog. Many think the Sprint Backlog is no more than the selected PBIs, so I think it is an important remark.
Final word
The Sprint Planning is one of my favourite sections of the 2020 Scrum Guide. It has fixed many of the issues from the past and highlighted the importance of the Sprint Goal to navigate through complexity.
For me, the Sprint Planning section has all it needs. It clearly describes who’s doing what and puts the self-managing Developers at the forefront. Product owners propose what they think will bring the most value next. Developers determine what they can do. Together they create the Sprint Goal, with the help of the Scrum Master.
The Sprint Goal will be leading throughout the Sprint. This will be very clear when I discuss the Daily Scrum in the next chapter of this journey.
