Sprint Planning

Scrum team planning a sprint.Sprint planning is the cleverly named event where the scrum team creates their plan for the sprint. The outputs from sprint planning are: the sprint goal, the forecast of which product backlog items will be delivered, and the team’s work plan.

Timing Of Sprint Planning

Sprint planning is held at the very beginning of the sprint. Our recommended time box for this meeting is two hours for a one week sprint. The 2020 Scrum Guide says the time box is eight hours for a month-long sprint, though I would hope your team is not considering month-long sprints. Remember, a time box is simply a limit. The meeting should never be longer than that. Ideally, you should be able to achieve the goal of sprint planning in far less time than the time box.

Sprint Goal

The sprint goal answers the question: Why is this sprint valuable? Think of it as the elevator pitch for the sprint. The product backlog items selected for the sprint should support the achievement of the sprint goal. For example, if we’re a consumer website, we might have a sprint goal of streamlining the checkout process for our customers. We might have several product backlog items, each a specific enhancement to help improve or streamline the checkout process. Each has a specific deliverable that adds meaningful value on its own. Together, they support the sprint goal of streamlining the checkout process.

The sprint goal is a really powerful concept because a well-crafted sprint goal is more important than the individual product backlog items that compose it. Over the course of the sprint, if the team identifies better ways to achieve the sprint goal, it might be reasonable for them to pursue those. They may even shift or change which specific product backlog items they deliver if by doing so they can do a better job of achieving the sprint goal.

Sprint Forecast

With the sprint goal in mind, the developers pull a set of backlog items into the sprint backlog. It’s important that the entire scrum team has full confidence that they can deliver these items to the stakeholders by the end of this sprint. This list of deliverables will be shared with the stakeholders and referred to as the sprint forecast.

Work Plan

The outcome of the sprint from the stakeholders’ point of view is the sprint goal and the individual product backlog items that compose the forecast. From the point of view of the scrum team, however, there is one more very important component: the team’s plan for what work they will do in order to achieve the sprint goal. Usually this plan is a big list of tasks. It’s worth mentioning that some tools call these sub-tasks, but I just call them tasks.

A task is an item of work, something that someone, a pair of someones, or even a whole group of people will do. For example: writing some code or doing some testing. The key difference between product backlog items and tasks is that tasks are actions while product backlog items are deliverables.
 

Sprint Planning Agenda

A sprint planning meeting can be organized into three phases: sprint goal, forecast, and work planning. In practice, there is usually some iteration back and forth as the team creates and adjusts the three components of the sprint backlog.

A well-run sprint planning session will spend most time in the third phase where the team is tasking and work planning. If the team has a good definition of sprint ready, the first and second phases move along quickly.

In the third phase the developers collaborate to identify all of the work required for each of the product backlog items in the forecast. Don’t expect that the developers can identify all of the work at this time, however. The nature of complex work is such that our understanding of what tasks will be needed is going to change as the team does the work. So in sprint planning, our task list is just a starting point.

After the developers have broken the product backlog items down into tasks, they may decide there is more work than expected, and they do not have full confidence they can deliver the set of product backlog items they originally said they could. This is okay — we are still in sprint planning.

The developers present the situation to the product owner, asking the product owner to remove product backlog items until they arrive at a set that the the whole team has full confidence they can deliver. In this way, the scrum team exits sprint planning with a sprint goal, a forecast, and a plan that they all believe will result in the achievement of the sprint goal.

Learn More

Share it!

Leave a Reply

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