Continuing on this series and look through the 2020 Scrum Guide we come upon Sprint Planning. This could get interesting as we’ve got more changes from 2017 to 2020 in this section…
Key points in the series so far:
- The word “Agile” appears exactly zero times.
- The Sprint time-box is in itself a time-box for the team to complete what it commits too. Which in turn holds them accountable. Which is then nothing more than pointing the finger when things aren’t finished.
Scrum Guide 2017
“The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box”
Scrum Guide 2020
“Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.”
– The 2017 Scrum Guide was more about procedure than collaboration during Sprint Planning. Providing time frames based on Sprint lengths with the Scrum Master being responsible for ensuring that the Sprint Planning occurs and that the team does not go outside the timebox. Now that is still in the 2020 Scrum Guide, its just at the end of the Sprint Planning section.
The 2020 Scrum Guide puts ownership of Sprint Planning on the Product Owner to make sure that attendees understand the Product Goal and the Product Backlog items that would help support that role. I do have some issues here that making statements like this take away from the collaborative nature of working in an agile way and places all of the pressure on one person to know what is best for the product. But then there is this…
“The Scrum Team may also invite other people to attend Sprint Planning to provide advice.” Which looks an awful lot like Scrum attempting to open the door to bringing your customer/user and your development team together. Also known as “On-Site Customer” from XP. I like this being in the latest Scrum Guide.
Scrum Guide 2020
Sprint Planning Topics:
“Topic One: Why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.”
– Pretty straight forward here. I just wish it would have continued with the “On-Site Customer” part a little more by stating “The Product Owner, along with any customer/user involvement, proposes how the product could increase its value and utility in the current Sprint.”
The Scrum Team collaborating on a Sprint Goal is a great idea. Where I have a problem is the use of the word “Stakeholders” as this often is used to mean “management or executives”, this is fine of course, if that is who we are building software for. But I am willing to bet we are building software for customers or users of the software. Perhaps we should be be stating why the Sprint Goal is valuable to our customers or users.
Finalizing the Sprint Goal prior to the end of Sprint Planning is just obvious, when else would you do that? Obviously scope might change a little here and there, but the goal of the Sprint shouldn’t change or be negatively impacted by that.
“Topic Two: What can be Done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.”
– Here we are working together to identify which backlog items support the Sprint Goal and even doing a little bit of refinement or narrowing of the scope of these items to achieve the Sprint Goal.
Let’s say you work for a mortgage lender, and you process mortgage loans. And let’s say that you are processing a loan and something is missing, so you need to suspend the loan in its current process until this missing something is provided. The art form to this is the Sprint Goal might be to “Add a suspense condition to a loan”. Well there are a number of things that go along with that.
- Ability to add a comment as to why the suspense condition was added
- Ability to add an activity type for the suspense condition
- Clearing a suspense condition
- Removing a suspense condition because it was added in error
- Capturing the userID of who entered the suspense condition
- Capture the date the suspense condition was added
- Capture the date the suspense condition was cleared
- Capture the date the suspense condition was removed due to error
- etc..,
Are all of these things on the list of functionality for adding a suspense condition? Sure they are things that Auditors or the system does, but are they all absolutely necessary to support the Sprint Goal of “Add a suspense condition to a loan”? No.
The narrowing of the scope to support the Sprint Goal is what provides the confidence from the team that they can achieve the Sprint Goal.
“Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.”
– This is where the team having insights into their own metrics is valuable to them. The Definition of Done is also a guide towards building a teams confidence in what they think they can accomplish.
Topic Three: How will the chosen work get done? For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
– So narrowing items down to tasks that take no longer than day is what Scrum prescribes. Notice again how we are talking about Product Backlog Items and not Stories. There is a major difference. If we are working in Stories, a Story is something that is deliverable on its own and provides some value to our customer or user. Scrum doesn’t use stories, I guess to avoid this skill set and to make it easy to adopt like “Any other project management framework”.
Neil Killick provides a great example of narrowing or slicing that I think applies to differentiating between what Scrum says with Product Backlog Items and what Agile uses with Stories.
You can see Neil talk about this here: https://www.youtube.com/watch?v=TJ2aS80OTKg
Think of Product Backlog Items as a Rubik’s Cube, and Stories like an Apple.
- If you break a Rubik’s Cube down into is individual pieces and build one of the squares, its not very useful and you don’t understand what you are trying to deliver. Our customer/users don’t know that it is a Rubik’s Cube you are building.
- If you take a slice through an apple, and deliver that slice of apple to a user, they know they are eating apple, even if they don’t have the stem or the core or the other side of the apple.
I think this is a fault in Scrum since I think Stories is where the value comes from. And Stories are domain driven from what the user does. Maybe this is another point of driving that divide between Scrum and Agile.
“The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.”
– This is what the team works from during the Sprint to guide them towards the Sprint and Product Goal.
“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”
– This is just giving a guideline of the timebox for the Sprint Planning.
Sprint Planning can be tiring depending on many factors. The size of the team, the size of the Sprint Goal, the demands/expectations of management, the demands/expectations of a Product Owner, and the complexity of the work involved in achieving the Sprint Goal.
Please let me know if you have any thoughts or want to share different experiences you have had with Sprint Planning.
Chris Pipito 