50% discount coupon

International SCRUM Master Foundation (Scrum Guideline 2020)

Steen Lerche-Jensen

5.2 Sprint Planning

In the beginning of a new sprint, a sprint planning meeting is held. The purpose of the sprint planning is to come up with a plan of work for the upcoming sprint. The sprint planning is a co-creation of the entire Scrum Team. This is a time-boxed meeting, which can take maximum 8 hours for a 4-week long sprint period and 4 hours in case of 14 days sprint interval.  The scrum master facilitates the meeting and makes sure that the meeting stays within the time-box.

Scrum Planning

Input to the Sprint Planning

Input to the sprint planning meeting includes:

  • Product backlog
  • Latest product increment
  • Projected capacity of the development team during the sprint
  • Past performance of the development team

It is 100% up to the development team to select the numbers of items from the product backlog for the sprint. The development team decides what they can accomplish and commit to for the upcoming sprint. This is where many scrum projects fail; we much too often see that the product owner forces product backlog items into a sprint without having a 100% commitment from the 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 3 topics:

  • Why is this Sprint valuable?
  • What can be Done this Sprint?
  • How will the chosen work get done?

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

WHAT 
The product owner explains and discusses the objective that the sprint should aim for and walks through the product backlog items that are involved in achieving this. The whole development team then collaborates on the understanding of the jobs of the sprint, and in this way the team can foresee the functionality that will be developed in the upcoming sprint. 

The development team agrees on a sprint goal during this process, showing the objectives that will be met through the development of the product backlog items selected. The sprint goal will show the team why to build the product increment.

HOW
Here, the sprint goal is created and the product backlog items for the sprint are chosen. It is time for the team to describe how they will build the functionality and which criteria have to be fulfilled before a product increment can be stated as 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 Backlog

Sprint Backlog

The development team often starts the sprint backlog process by designing the system and the tasks needed to turn the product backlog item into a working product increment. In scrum, the word task(s) is used to refer to the work that needs to be performed – these are the small icons you can see in the drawing in the column To-do, In Progress, and Done and they represent a piece of work that moves from To do towards Done.

The work/ tasks might be of different amount, and also the estimates might vary task by task. Therefore, in the sprint planning meeting, the development team creates a number of tasks so that they can forecast what they will be able to deliver by the end of the sprint. By the end of the sprint planning meeting, the team has split the work to be done per product backlog items into smaller tasks, which often take less than one day.

At least, the team has come so far that it has enough tasks to work on for the first couple of days. There is no leader or scrum master to say who shall work on a specific task. The development team is 100% self-organized from start to the end of a sprint. Everybody on the team is committed to all tasks.

After the backlog items are split into tasks by the development team, the product owner stands ready to clarify any issues that come from the development team members, and he might even be ready for making some trade-offs. The development team can also renegotiate the chosen product backlog items with the product owner, if the team sees that they have too much or too little work for the sprint. Sometimes, the team or the product owner invites others to attend the sprint planning meeting – it can be technical staff, or it can be people with in depth domain knowledge. Most importantly, the development team needs to have a clear understanding of what they need to deliver; otherwise, 100% commitment is not possible.

What Is the Sprint Goal

The sprint goal is used as a guideline by the development team, showing them why they are developing the product increment, and how they can achieve the goal through implementing the items from the product backlog.  The sprint goal is a short description (2-3 sentences) of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.

The sprint goal is determined in collaboration by the development team, product owner, and scrum master.

The sprint goal should be visible while developing the product increment to make sure the development team is building and fulfilling the objectives when implementing functionality and technology. In some situations, the work can take an unexpected turn and look different than expected, and the development team can then change the scope of the sprint backlog in collaboration with the product owner. This should not happen often, and it must be discussed in the retrospective – what was the reason and how it can be avoided in upcoming sprints.

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