Sprint Planning

Home » Sprint Planning

The 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.

Sprint Planning addresses the following topics: [– see below –]

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

The time-box is not the desired or suggested but the maximum length for this event. Many teams can halve this time and some can go even further. The time box is a cap that serves as a reminder that a planning event stretching longer than that is either poorly organized or its goal is misunderstood.

Moreover, backlog refinement was not always part of the Guide, thus there was a genuine chance that the planning event could take very long. The introduction of backlog refinement largely eliminates this risk.

Sprint Planning Participants

  • Scrum Master: ensures the planning reaches its goal;
  • Product Owner: communicates which Product Backlog items are the candidates for the Sprint, explains business goals to the Developers, negotiates trade-offs if plausible;
  • Developers: Learn all details necessary for delivering an increment, estimate its delivery potential and forecast the outcome of the Sprint, and create a Sprint Backlog;
  • Optionally external domain experts, and stakeholders invited by the Product Owner: if the complexity of the product requires, the Product Owner involves further experts;
  • Optionally external specialists invited by the Developers.

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.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

With the 2020 Scrum Guide, the Sprint Goal got its own topic number and received place number one. This clearly underlines how important the Spring Goal is for the creators of Scrum. It is very clear that working towards a goal is mentally more efficient than working on a set of unrelated tasks. It is important to emphasize that the Sprint Goal can be met even if some individual Product Backlog items selected for the Sprint are not “Done”. The team is looking at a goal, not a scope.

However, in practice, setting a goal may not be as straightforward as it seems. The highest-ranked Product Backlog items may not add up to a coherent goal. Having a Sprint Goal is a good technique since a good goal increases the chance of successful, coherent delivery. However, there is an apparent possibility of conflict between maximizing the value delivered by the Scrum Team and organizing the Sprints around a single goal. Nevertheless, the planning should start with the assumption that finding a good goal is possible and desirable. Besides, having 2 goals is still better than having 15 unrelated product backlog items without any goal.

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.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

This part of the planning is a negotiation between the Product Owner and the Developers:

  • The Product Owner knows the importance and business content of the product backlog items. During the discussion with the Developers, it might be possible to revise, ameliorate or replace backlog items.
  • The Developers know their limits and would only take as many product backlog items as they can confidently deliver. It would be pointless to force them to let in more tasks. On the other hand, the Product Owner may reorder the backlog if the Developers’ forecast does not meet his or her anticipations.

Typical inputs to this topic are:

  • the Product Backlog: an ordered list of the deliverables as described in the Product Backlog chapter;
  • the latest product Increment: the work delivered as described in the Increment chapter; Ideally it has been inspected on the Review meeting and the feedback is collected; less ideally it contains leftover work yet to be done;
  • the projected capacity of the Development Team during the Sprint: in real terms, the number of available workdays of team members with given skills in the coming Sprint; The measurement unit is not necessarily ‘workday’;
  • and past performance of the Development Team: traditionally measured as velocity (story points delivered per sprint). ‘Past performance’ can be anything that guides the team to assess its delivery capability.

It is good to recall the definition of the Sprint Backlog to understand the desired outcome:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

The Scrum Guide – Sprint Backlog chapter

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.

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.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

© 2020 Ken Schwaber and Jeff Sutherland

Commentary

The popular way of creating this part of the Sprint Backlog is the task breakdown of the Product Backlog items. These tasks represent the work to be done in the Sprint. The early versions of the Guide included this technique as a tip. The Guide does not recommend techniques anymore, however, for most teams creating a task breakdown is still the best option. Considering the agility of the process, the breakdown does not have to address all Product Backlog items at this stage, only enough to start the Sprint with.

In the course of creating the delivery plan, teams may consider several factors. Including, but not limited to:

  • identified dependencies,
  • actions imposed by the Definition of Done,
  • organizational requirements,
  • specialist skills,
  • occasionally the contribution of external experts who are not part of the team,
  • cooperation with other teams,
  • anticipated support tasks, e.g. issues in the production system.

The phase of planning may bring unexpected issues to the surface. Implementing certain product backlog items can prove to be more challenging than initially thought. For this reason, the presence of the Product Owner throughout the entire planning session is highly beneficial.

Key Takeaways

  • The Sprint Planning consists of three topics, where each topic is important:
  • This is the event where the team can invite external experts.
  • Timebox: maximum 8 hours for a one-month Sprint, less for shorter sprints, does not depend on team size.
  • Backlog refinement (and preparation) is essential, without it, the Sprint Planning can spiral out of control.
  • The Scrum Master is accountable for a productive event but does not have to be there.
  • The Product Owner is accountable for clearly communicating the Product Backlog items and negotiating with the Developers, but can also delegate it to the Developers.

External content: Scrum.org’s video about Sprint Planning facilitation

Scrum.org’s YouTube video about facilitating Sprint Planning

This section of the Guide went through serious evolution during the last decade:

  • It does not contain tools, techniques, or practices anymore. This is great from a methodological point of view: every team can choose what best suits their needs. (On the other hand, the reader has to seek guidance elsewhere.)
  • Previously, the planning was a combination of two meetings: one between the Product Owner and the Developers (that time called as Development Team), and the other was just for the Developers. Now we only have the 3 topics to discuss in a single meeting.

The Scrum Guide – 2017

Sprint Planning

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.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Topic Two: How will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

©2017 Ken Schwaber and Jeff Sutherland.

The Scrum Guide – 2010

The ‘Release Planning Meeting’ section was not carried over and has no corresponding section in the later Scrum Guides.

Release Planning Meeting

The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate. Release planning answers the questions, “How can we turn the vision into a winning product in best possible way? How can we meet or exceed the desired customer satisfaction and Return on Investment?” The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.

Release planning is entirely optional. If Scrum teams start work without the meeting, the absence of its artifacts will become apparent as an impediment that needs to be resolved. Work to resolve the impediment will become an item in the Product Backlog.

Products are built iteratively using Scrum, wherein each Sprint creates an increment of the product, starting with the most valuable and riskiest. More and more Sprints create additional increments of the product. Each increment is a potentially shippable slice of the entire product. When enough increments have been created for the Product to be of value, of use to its investors, the product is released.

Most organizations already have a release planning process, and in most of these processes most of the planning is done at the beginning of the release and left unchanged as time passes. In Scrum release planning, an overall goal and probable outcomes are defined. This release planning usually requires no more than 15-20% of the time an organization consumed to build a traditional release plan. However, a Scrum release performs just-in-time planning every Sprint Review and Sprint Planning meeting, as well as daily just-in-time planning at every Daily Scrum meeting. Overall, Scrum release efforts probably consume slightly more effort than tradition release planning efforts.

Release planning requires estimating and prioritizing the Product Backlog for the Release. There are many techniques for doing so that lie outside the purview of Scrum but are nonetheless useful when used with it.

©2017 Ken Schwaber and Jeff Sutherland.

Sprint Planning Meeting

The Sprint Planning meeting is when the iteration is planned. It is time-boxed to eight hours for a one month Sprint. For shorter Sprints, allocate proportionately less of the total Sprint length to this meeting (for example, two weeks would be a four-hour Sprint Planning Meeting). The Sprint Planning Meeting consists of two parts. The first part is when what will be done in the Sprint is decided upon. The second part (a four-hour time-box for a monthly Sprint) is when the Team figures out how it is going to build this functionality into a product increment during the Sprint.

There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?” part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of “What?” Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint.

Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that will be met through the implementation of the Product Backlog. This is a statement that provides guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release goal.

The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.

In the second part of the Sprint Planning Meeting, the Team addresses the question of “How?” During the second part of the Sprint Planning Meeting (four hour time-box for a monthly Sprint), the Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) into a done increment. The Team usually starts by designing the work. While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day. This task list is called the Sprint
Backlog. The Team self-organizes to undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time
during the Sprint.

The Product Owner is present during the second part of the Sprint Planning Meeting to clarify the Product Backlog and to help make trade-offs. If the Team
determines that it has too much or too little work, it may renegotiate the Product Backlog with the Product Owner. The Team may also invite other people to attend in order to provide technical or domain advice. A new Team often first realizes that it will either sink or swim as a Team, not individually, in this meeting. The Team realizes that it must rely on itself. As it realizes this, it starts to self-organize to take on the characteristics and behavior of a real Team.

Tip
Usually, only 60-70% of the total Sprint Backlog will be devised in the Sprint Planning meeting. The rest is stubbed out for later detailing, or given large estimates that will be decomposed later in the Sprint.

© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved

What are your thoughts?

Your email address will not be published. Required fields are marked *