Sprint planning

Sprint planning is the timeboxed event that opens a Sprint by deciding why it matters, what the team will deliver and how the work gets done. The whole Scrum team attends, and the plan they agree on becomes the Sprint Backlog.

This is one meeting, not a method — one event, with a start, a finish and a defined output. It is where a Sprint Goal gets agreed, Backlog items get selected, and the work gets broken down far enough that the team can start.

Sprint planning sits inside a wider shift in how a company works. An agile transformation changes funding, governance and reporting; this page is only about the event at the front of each Sprint.

The live scrum master offshore page covers who facilitates the session. This page covers the session itself and what it has to produce before anyone leaves.

Key takeaways

• Sprint planning answers three questions: why the Sprint is valuable, what fits, and how it gets done.
• The Sprint Goal must be finalised before the event ends.
• The event is capped at eight hours for a one-month Sprint, and usually runs shorter.
• The Sprint Goal, the selected items and the plan together form the Sprint Backlog.

How it works

Sprint planning opens the Sprint by laying out the work to be performed, and the whole Scrum team builds the plan together. The Product Owner makes sure attendees arrive ready to discuss the most important Backlog items.

Topic one settles value. The Product Owner proposes how the product could become more useful this Sprint, and the team turns that into a Sprint Goal explaining to stakeholders why the Sprint is worth running.

Topic two settles scope. Developers pick items from the Product Backlog in discussion with the Product Owner, refining them as they go, and their forecast improves with what they know about past performance and capacity.

Topic three settles method. For each selected item the Developers plan the work needed to meet the Definition of Done, often by breaking items into pieces of one day or less — and nobody outside the team tells them how.

Preparation decides the length. A Backlog refined during the previous Sprint turns planning into a decision meeting — an unrefined one turns it into a discovery workshop that overruns every single time.

The event has a ceiling. The Scrum Guide timeboxes the session to a maximum of eight hours for a one-month Sprint, and shorter Sprints usually take proportionally less time.

UK government teams work to the same habit. The GOV.UK Service Manual names keeping planning going as one of five core principles every government service must follow, alongside focusing on user needs.

Scaling changes the frame, not the event. Inside an agile release train, teams still run their own sprint planning after a shared planning interval has set the direction for the next few months.

Outsourced teams need one extra habit: written output. Where delivery runs through agile outsourcing, the Sprint Goal and the selected items belong in the tracker before the call ends, not in somebody’s notebook.

The same discipline travels outside software. An agile marketing team runs the same three topics against campaign work, picking a goal, selecting items and breaking them down before the fortnight starts.

Examples

Sprint planning looks different by Sprint length and by how far apart the team sits, but the three topics never move. Here is how the event plays out in four common delivery setups.

A two-week Sprint in a product company. Planning runs about three hours: forty minutes on the goal, ninety minutes selecting and refining items, and the rest breaking work into pieces of a day or less.

An offshore development team in Bengaluru serving a London client. Planning sits in the afternoon overlap, the Product Owner joins live for topics one and two, and the Developers finish topic three on their own.

A government service team working to the GOV.UK Service Manual. The Sprint Goal is written against a named user need, and the team shows the increment to real users before the next planning session opens.

A support team at a business process outsourcing (BPO) provider running two-week Sprints against an automation backlog. The Product Owner is the operations manager, and the goal is stated as a handling time target.

What all four share is the output. Nobody leaves the room without a Sprint Goal, a selected set of items and enough of a plan to start work the following morning without another meeting.

Related terms

• agile portfolio management: funding and prioritising work across many teams, well above the Sprint.
• integrated business planning: the monthly finance and operations cycle, running on a different clock entirely.
• agile release train: the group of teams whose shared planning interval sets the direction each Sprint works inside.
• agile outsourcing: agile delivery run with an external provider, where planning habits need writing down.
• scrum master offshore: the person who facilitates the event when the team sits in another time zone.

FAQ

How long should sprint planning take?

Eight hours is the ceiling for a one-month Sprint, and shorter Sprints take less. Two-week Sprints commonly run two to four hours.

Who attends sprint planning?

The whole Scrum team: the Product Owner, the Scrum Master and the Developers. The team can also invite other people in to give advice.

What comes out of sprint planning?

The Sprint Goal, the Backlog items selected for the Sprint, and the plan for delivering them. Together those three things are the Sprint Backlog.

Who decides how much work fits in a Sprint?

The Developers do, in discussion with the Product Owner. Their forecast improves as they learn more about past performance, upcoming capacity and their Definition of Done.

Can the Sprint Goal change after planning?

No — the goal is finalised before the event ends, and work that no longer serves it gets renegotiated with the Product Owner instead.

Compare providers running agile delivery teams in the Outsource Accelerator BPO hubs.