Sprint Planning

Scrum team planning a sprint.Sprint planning is the very cleverly named event (meeting) where the whole 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. The time box for this meeting is two hours for a one week sprint. The Scrum Guide says the time box is eight hours for a four week sprint, though I would hope your team is not considering four week 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 less time than two hours if you’re doing a one week sprint.

Sprint Forecast

A goal of sprint planning is to identify a set of product backlog items that the entire scrum team has full confidence that they can deliver to the business by the end of this sprint. Each of these product backlog items is valuable to stakeholders. This list of deliverables will be shared with the stakeholders and referred to as the sprint forecast. It is the set of product backlog items that the team is predicting they will deliver to the business by the end of the sprint.

Sprint Goal

The product backlog items in the sprint should support the achievement of an overarching 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.

Work Plan

The outcome of the sprint from the business’s point of view is the sprint goal and the individual product backlog items that compose the sprint goal. From the point of view of the scrum team, however, there is one more very important component in the output of a sprint planning meeting: 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 or perhaps a pair 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 outcomes.

Sprint Planning Agenda

Traditionally, a sprint planning meeting has a two-phase structure. In the first phase, the team is committing to a set of product backlog items and crafting the sprint goal. In the second phase, the development team does a work planning session to identify the tasks they need to work on in order to achieve that goal.

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

In the second phase of a traditional sprint planning meeting the team self-organizes to identify all of the work required for each of the product backlog items in the forecast. Don’t expect that the team 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 team has 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 the sprint planning meeting.

The development team presents the situation to the product owner, asking the product owner to remove product backlog items until they arrive at a set that the team has full confidence they can deliver. In this way, the whole team exits the sprint planning meeting 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.