Sprint Planning is one of the five Scrum Events. The Scrum Guide 2020 has expanded Sprint Planning by one topic and now addresses not only the “What” and the “How”, but now also the “Why”. This is an important addition that also places the focus on the product goal. Read on to learn more about the new structure of Sprint Planning and how to conduct it successfully.
Sprint Planning Is the Basis for a Successful Sprint
Sprint Planning is one of the five Scrum Events. The other events are the Daily Scrum, the Sprint Review, the Sprint Retrospective and the Sprint itself, as a container for the other events.
Sprint Planning initiates the Sprint by defining the Sprint Goal and the work to be performed in the Sprint. The resulting plan is created through the collaborative efforts of the entire Scrum team.
Sprint planning for a one-month sprint is limited to a timebox of no more than 8 hours. For shorter sprints, it usually takes proportionally less time.
The Scrum Master ensures that the event takes place and that the participants understand its purpose. He moderates the meeting and helps the Scrum team to complete successfully the Sprint Planning within the defined timebox. The Scrum Team can also invite other people to the Sprint Planning for consultation.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. He explains the priorities to the Developers, helps with questions about the planned product increment and, if necessary, with decision making.
The Sprint Planning Topics
In the Scrum Guide 2017 there were only two planning parts, Topic 1, which defined the “What” and Topic 2, which described the “How”, i.e. how the plan is created. A new important part has been added: the “Why”.
Sprint Planning addresses the following three Topics of equal duration.
Topic One: Why is this Sprint valuable?
Topic Two: What can be Done this Sprint?
Topic Three: How will the chosen work get done?
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.
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.
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.
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 (PBI’s) 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.
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.
The Inputs for a Successful Sprint Planning
While Topic 1 is about why the sprint has value and contributes to the product goal, Topic 2 is about how many of the prioritized backlog items can be implemented. Topic 3 will be primarily about technical aspects of how the planned increment will be developed. For a successful Sprint Planning, you need some inputs. Read more about this in the next sections.
The whole Scrum Team participates in Sprint Planning. It can also be useful to invite other people, e.g. users of the software or specialists, to Sprint Planning, because they know the requirements of the product or system. This is helpful, for example, to better understand the requirements. Representatives of specialist departments can also be invited, especially if their support is required during the sprint. The following figure shows the process of Sprint Planning with the Sprint Backlog as the goal.
As you can see in the figure, successful Sprint Planning requires the following input:
- An idea for the Sprint Goal that the Product Owner has ready, which is then discussed in Sprint Planning.
- The Product Backlog entries that will potentially be included in the Sprint Backlog.
- Developers should know their velocity and capacity approximately so they can determine how many Product Backlog Items (PBI’s) they can implement in the Sprint.
- An earlier Scrum Guide recommended including in the Sprint Backlog at least one high-priority process improvement identified in the last Retrospective. Lessons learned from the last Sprint should be incorporated into the next Sprint Planning in order to keep getting better.
Sprint Planning has clearly gained value with the new Scrum Guide 2020. The Sprint Goal already existed in the past, but now it is even more important.
Product Backlog Items Must Be Ready
The Product Backlog Items (PBIs) that the Scrum team includes in Sprint Planning must be Ready. You may wonder what this means. It’s quickly explained.
The Definition of Ready (DoR) does not appear in the Scrum Guide 2020, but it is very useful. It is a list of criteria that define if the Product Backlog Items are ready to be worked on immediately in the Sprint. It is mainly about the quality, completeness, etc. of the Product Backlog Items. If they meet the criteria, then they are READY.
Here You Can Find Even More Knowledge
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!
