Skip to content
Home » Scrum articles » Sprint Planning

Sprint Planning

At the beginning a new Sprint, before we can do any work, we need to plan what we are going to work on. Sprint Planning provides the structure for the team to define its goal for the Sprint (the Sprint Goal), the list of work items selected for execution during the Sprint (the “What” in the Sprint Backlog), and the plan on how the team is going to execute the work (the “How” in the Sprint Backlog). Three important activities take place at Sprint Planning:

Activity #1: Setting the “Why”

At Sprint Planning, the Scrum Team, working collaboratively, decides the Sprint Goal. This is the objective that we are setting up for ourselves and that we want to achieve by the end of the Sprint. All the work we will do in the Sprint should align to and allow us to achieve the Sprint Goal. The Sprint Goal provides the “Why” (why we are doing the work), and gives guidance to the Developers as to where to focus their efforts.

Activity #2: Setting the “What”

The Product Owner provides guidance and context on the most important work to do in the Sprint and shares a list of priority items selected from the Product Backlog.

The Developers, having established their capacity for the Sprint, decide how many of the work items proposed by the Product Owner they can effectively commit to complete within the Sprint. (Read this article for more information on capacity and velocity). The Developers can push back on excessive demands from the Product Owner if they feel that the work requested does not fit within the available capacity for the Sprint. The goal here is for the Developers to set a reasonable commitment for the work they can get 100% completed in the Sprint.

Ultimately, the Developers select a list of work items (PBIs, Product Backlog Items) that they are committing to deliver this Sprint, and put them in the Sprint Backlog. The commitment should not be taken lightly: it is important for the Developers to select the right amount of work they can effectively complete 100% by the end of the Sprint. This is not about setting unreasonable expectations, nor is about setting stretch goals. The commitment here is a signal to the Product Owner (and the rest of the stakeholders) on what they can expect the team will deliver by the end of the Sprint. By setting the right expectations, and committing to deliver on these expectations, the Scrum team builds trust with the rest of the organization.

On the other end, the commitment should not be punitive if not met: we all live in reality and unexpected events and circumstances always happen. And if the team is not able to complete all the work 100% by the end of the Sprint, be it: we learn, we adjust our capacity measures, and we will do better in the next Sprint. However, this should not be an excuse for not meeting the commitment all the time. The expectation should be that whatever the Developers select in the Sprint Backlog, they will deliver 100% by the end of the Sprint.

Activity #3: Setting the “How”

Finally, the Developers create a plan on how to execute the work. They look at the work items selected for the Sprint Backlog, and decide how to execute the work: who is doing what? Do we need extra help from external teams? Do we have dependencies to account for? Do we know how to do the work? Etcetera.

At this point, the Product Owner may not be very active in the conversation as the Developers mainly discuss how to execute the work. However, it’s useful for the Product Owner to participate as he or she may answer questions that the Developers may have about the work itself or about the expectations for the Sprint.

This plan represents the “How” and it also goes in the Sprint Backlog.

Sprint Planning

Learn more about the Scrum framework with more information on specific events:


Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

Download the Scrum Events PDF

Leave a Reply