50% discount coupon

International Scrum Master Foundation

Steen Lerche-Jensen

6.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 development team, scrum master, and the product owner. 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.

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 sprint planning meeting is split into 2 subsections:

  • WHAT-meeting: What product increment can we as a team deliver in the upcoming sprint.
  • HOW-meeting: How do we work to secure the delivery of the product increment that we commit to?

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.

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. In other words, the increment is developed, tested, and documented according to agreement in a way that it will be potentially shippable. The product backlog items and the plan for How to deliver them is called the 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.

Use the promo code: smfacademy15 and get 15% discount for the International Scrum Master Foundation Certification