The Workshop: Sprint Planning

Two weeks, one goal, a plan everyone in the room committed to. Sprint Planning is the workshop where a refined backlog becomes a sprint – a contract about what you’ll learn by the end, not a to-do list with a deadline. For the worked example, see Turning Sticky Notes into Delivery.

Sprint Planning

Sprint Planning turns a refined, prioritised backlog into a sprint the team can commit to: a single clear goal, a set of stories selected against capacity – the team’s available time this sprint, expressed in points or hours – a concrete task breakdown, and a stated commitment from everyone in the room. Often just called planning or iteration planning. Sometimes confused with roadmap planning (roadmap planning spans months; sprint planning spans one sprint) and with the ongoing story-preparation work that should happen before planning, not inside it. The ritual comes from Scrum, but the pattern – “here is what we will do and here is why we believe it” – predates Scrum by decades and shows up in every delivery discipline under a different name.

What’s It For

A team finishes a sprint having delivered six of the eight stories they pulled in. The two unfinished stories get carried over. The next sprint they pull in ten stories to “catch up” and finish five. The sprint after that they pull in twelve. Velocity – the team’s average completed points per sprint, smoothed over the last few sprints – is now invisible, commitment has become theatre, and the team quietly stops believing the numbers.

What went wrong wasn’t the work. It was the planning. Nobody said out loud what the sprint was actually for. Stories got pulled in because they were next in the list, not because they served a goal. When a fire came up mid-sprint, the team had no way to decide whether to fight it or park it, because there was no goal to measure the fire against. Every sprint became a slightly different version of “do as much as possible,” which is indistinguishable from “do whatever’s loudest.”

Sprint Planning exists to break that pattern. The sprint goal is the contract. The stories are the plan. When the plan has to change – and it always does – the goal is the thing you steer by. Without a goal, a sprint is a to-do list. With one, it’s a commitment.

Reach for it when:

You work in sprints of one or two weeks
The top of the backlog has been refined – stories have acceptance criteria, have been through Example Mapping or equivalent, and are sized
The whole team can attend
Someone can articulate what the sprint should achieve, not just what should be done

What It’s Not For

Skip it when:

The top of the backlog is a mess. Prepare the stories first, in a separate session; planning is not story preparation with an audience. Example Mapping is the usual gate before planning.
The team operates in continuous flow and has no sprint boundary.
You’re planning more than one sprint ahead – that’s roadmap work, a different session.
The product owner can’t attend. Reschedule.

Stop a session that’s already started if:

Three stories in a row need preparation work mid-planning – the top of the backlog isn’t ready; end the session, schedule the preparation, and come back
The product owner won’t accept capacity as a constraint – that’s a systemic problem, not a session problem
Two sprints in a row the committed plan wasn’t achievable – the sprint length, the preparation process, or the estimation practice is broken, not the planning session

Ending planning and scheduling something else is not failure. Committing to a sprint nobody believes is.

Definitions & Background

The sprint goal is one sentence describing what the sprint must achieve. Not a list. A capability the team delivers, a metric they move, a problem they solve. “Subscribers can pause and resume their subscriptions through the web app” is a goal. “Make progress on the subscription area” is not.

Capacity is not velocity. Velocity is a historical average – what the team has delivered over recent sprints. Capacity is this sprint’s actually-available time: velocity, minus on-call rotations, minus holidays and leave, minus scheduled meetings outside the sprint cadence, minus carry-over – stories committed last sprint that didn’t ship – still in flight. Teams that plan to last sprint’s velocity in a sprint with two people on holiday over-commit by definition.

Points are abstract sizing units, usually a Fibonacci-like 1/2/3/5/8/13 scale. T-shirt sizes or hours work too; the unit matters less than using the same one consistently.

The four phases – set, select, break down, commit – each have a different shape:

Goal-setting is a conversation between the product owner and the team, moderated by the facilitator. The product owner proposes, the team pressure-tests, the facilitator writes the agreed goal somewhere everyone can see it for the rest of the session.
Story selection is a negotiation. The product owner defends priority; the team asserts capacity; the facilitator holds the capacity number honest.
Task breakdown is team work. The product owner is available for questions but not driving. Developers, testers, and ops decompose each story into tasks that fit inside a day.
Commitment check is a round-the-room moment. Each person says, in their own words, whether they believe the plan is achievable. This is the contract.

If any of the four collapse into the others, the ritual stops working.

Inputs

A refined backlog – stories at the top with acceptance criteria, sized, and through Example Mapping or equivalent. A story that hasn’t been through Example Mapping is not ready to plan; plan it anyway and you’ll be mid-sprint when you find out why.
The team’s actual capacity for this sprint – velocity, minus on-call rotations, minus holidays and leave, minus carry-over still in flight. Calculate this before the session starts and write it on the board.
Recent velocity – the average of the last three delivered totals, not committed totals.
The whole team available for the duration of the session.

Nothing else needs to be prepared in-session – if it does, the preparation didn’t happen. If the backlog is chaotic, User Story Mapping is where that gets fixed, not in planning. If the sprint goal can’t be traced back to a meaningful outcome, Impact Mapping is the upstream conversation.

Outputs

What lands at the end of the session:

A sprint goal the whole team can state from memory – the one line that makes mid-sprint trade-offs decidable.
A selected set of stories that fits inside capacity, with priority order intact.
A task breakdown for each story, concrete enough that the daily standup has something to work against.
An explicit commitment from everyone in the room – not silent acquiescence.
Visible dependencies, on-call load, and carry-over so the sprint doesn’t break on something the plan didn’t acknowledge.

Photograph the whiteboard if the task breakdown happened on physical sticky notes. The sprint goal goes where everyone can see it: team board, wiki, Slack topic, the top of the sprint in the tracker.

These outputs feed straight into:

Retrospectives – the retrospective is where you notice that planning sessions have become theatre and fix the ritual before it fully collapses.
Ensemble Programming – when the task breakdown keeps flagging one developer as the sole person who can touch a system, ensemble work is the pattern that breaks the bottleneck.

Who’s Needed

The whole team, typically 4-9 people, for one hour per sprint week:

Facilitator. Runs the session, holds the clock, keeps the team off preparation detours. Often the Scrum Master (the role that protects the team from disruption and removes blockers), team lead, or a rotating role.
Product owner. Mandatory. They set the sprint goal, explain the stories, and make the trade-off calls when capacity doesn’t match ambition. Without them in the room, you are planning to build the wrong thing.
Developers. The whole development team. Sprint Planning is the one meeting where partial attendance breaks the ritual – if a developer isn’t in the room, they haven’t committed, and the commitment is the whole point.
Tester / QA. If they sit with the team, they’re part of the team, and they plan with the team. Testing capacity is capacity. Treat it that way.
Operations / SRE. For any team whose sprint includes deployment work, on-call rotations, or infrastructure change, ops is a first-class planning participant. On-call load is a real capacity drain and if it isn’t in the plan it will consume the plan anyway.

Sprint Planning is one of the few patterns that scales with team size – larger teams need longer sessions, not different ones.

Who to leave out:

Stakeholders. They shape the backlog before planning and see the output afterwards. They don’t attend planning itself. Observers warp the commitment conversation because people self-censor in front of the people they serve.
Other teams. Dependencies on other teams belong in the task breakdown as risks, not in the room as people.
Senior leaders with “just a quick ask.” The just-a-quick-ask is the thing that destroys the sprint goal you’re supposed to be setting. Leadership input happens in the story-preparation work upstream of planning, not in planning itself.

How To Run It

Phase	Duration (1-week sprint)	Duration (2-week sprint)	Key question
Sprint goal	10 min	15 min	“What must this sprint achieve?”
Story selection	20 min	40 min	“What fits, against real capacity?”
Task breakdown	25 min	50 min	“What are the concrete steps?”
Commitment check	5 min	10 min	“Does everyone believe we can do this?”
Total	1 hour	~2 hours

The rule of thumb is one hour per sprint week. Most teams beat that once they’ve run the pattern a few times and once upstream story preparation is reliable. If you’re consistently running longer, the problem is upstream: stories are arriving at planning unready.

Phase 1 – Sprint goal (10-15 minutes)

Before any story is discussed, the product owner proposes a sprint goal. Not a list. A sentence.

Open with:

“Before we look at stories, let’s agree what this sprint is for. Product owner, if we could only ship one thing this sprint – one capability the team delivers, one metric we move, one problem we solve – what is it?”

Write whatever they say on the whiteboard. Then pressure-test it with the team:

“Is this achievable in one sprint? Is this worth a sprint? Does everyone in this room understand why this matters?”

The goal should be specific, achievable in one sprint, and measurable or demonstrable. A good goal sounds like: “Subscribers can pause and resume their subscriptions through the web app.” A bad goal sounds like: “Make progress on the subscription area.”

Once the team accepts the goal, write it in large letters at the top of the whiteboard. Everything that follows is in service of this goal.

What to watch for:

No goal, just a list. The product owner says “let’s just pull in as much as we can.” Push back: “If we could only ship one thing this sprint, what would it be?” Refuse to move to story selection until a goal is on the board.
Vague goal. “Make progress on subscriptions” is not a goal. Push: “What would a subscriber be able to do at the end of this sprint that they can’t do now?”
Three goals disguised as one. “Pause, resume, and billing integration” is a roadmap item, not a sprint goal. Help the product owner pick the most important one; the others come next sprint.
SRE sprint goal looks different. For an ops-heavy sprint, the goal might be “Reduce deployment rollback rate from 1 in 5 to 1 in 20” or “Move the billing cron to the new scheduler with zero missed runs.” Same shape, same test: specific, achievable, demonstrable.

Phase 2 – Story selection (20-40 minutes)

Start from the top of the backlog. For each story, the product owner gives a thirty-second explanation of what it is and why it serves the sprint goal. The team confirms they understand it (a quick nod around the room is enough – if it’s more than a nod, the story wasn’t refined). Then the team decides whether it fits.

Keep a running tally of points (or t-shirt sizes, or hours, or whatever you size in) against capacity, visible at the edge of the whiteboard. When the tally reaches capacity, stop pulling.

Capacity, not velocity. Velocity is the historical average; capacity is this sprint’s actually-available time. Plan to capacity, not velocity.

Say it explicitly when you get there:

“We’re at 24 points. That’s our capacity. Any story we pull in now has to push another one out. Product owner, is there a trade you want to make?”

What to watch for:

Over-commitment. The team pulls in more than their average velocity because “this sprint feels different.” It never is. Use the velocity. Optimism is not a planning strategy, and a team that over-commits twice loses the ability to trust itself.
Under-commitment. The team sandbagging because they got burned. A sprint or two of under-commitment to rebuild confidence is fine; persistent under-commitment means the stories are bigger than estimated or there’s hidden work the estimates don’t cover.
Skipping the priority order. “Let’s skip story 3 and do story 7 instead.” Only the product owner can approve a priority swap, and they should say why out loud. Otherwise the backlog order stops meaning anything.
Gold-plating during selection. The team starts redesigning a story. Redirect: “We’re deciding what’s in, not how to build it. Task breakdown is next.”
Carry-over invisible. Last sprint’s unfinished work is coming in. Make it visible in the tally: “We have 8 points of carry-over. That leaves 16 for new work.” Carry-over that isn’t counted is how velocity quietly disappears.

Phase 3 – Task breakdown (25-50 minutes)

For each selected story, the team breaks it into tasks. A task is concrete enough that one person can do it in a day or less.

The facilitator’s job in this phase is mostly to keep moving. Give each story a time budget (“five minutes per story”) and hold it. If a story needs more than five minutes of task breakdown, it wasn’t ready for planning – pull it and prepare it separately.

For each story, the team identifies:

What needs to happen – the concrete tasks, written on sticky notes or into the tracker
Who’s likely to do what – not assignments, but a flag for tasks that need specific expertise
Dependencies – between tasks, between stories, between teams
The not-obvious work – testing, deployment, migration, documentation, feature flag cleanup, on-call handover

What to watch for:

Tasks that are too big. “Build the UI for pausing” is probably three tasks: form, validation, API wiring. If a task is longer than a day, split it.
Missing the unglamorous work. Teams forget testing, migrations, deployment, feature flag management, observability wiring, documentation updates, on-call runbook edits. Prompt: “What else has to happen before we can call this done?”
One-person bottlenecks. If every story has the same developer flagged as essential, that’s a risk. Don’t solve it now – flag it and discuss pairing or knowledge-sharing in the retrospective.
External team dependencies. If a task needs another team’s API, approval, or review, name it and name the person who’ll chase it. Better still: can you start with a mock or stub so the dependency isn’t blocking?
On-call capacity. If a developer is carrying the pager this sprint, their capacity is not the same as a developer who isn’t. Build that in during task assignment, not after the fact.

Phase 4 – Commitment check (5-10 minutes)

Read the sprint goal aloud. Read the list of selected stories. Then go round the room and ask each person the same question:

“Do you believe we can deliver this sprint as planned?”

This is not a vote. It’s a check. You are looking for the person whose body language doesn’t match their words. You are giving the quiet team member a direct invitation to raise a concern that would otherwise stay silent until the retrospective.

Run a silent confidence check before any verbal round-the-room: “On a count of three, hold up fingers from one to five. One means you don’t believe we can deliver this sprint. Five means you’re confident. Three is the middle. No talking yet.” Anything below a four gets a follow-up question: “You held up a two. Which story is the worry, and what would lift it?”

The silent signal goes first because round-the-room polling, with senior people answering early, pressures introverts and juniors toward conformity – by the time the second person speaks, the room has anchored. Silent first surfaces the dissent that the verbal round would flatten.

If someone says “we’ll try,” it’s a signal – ask one more question: “What would turn ‘we’ll try’ into ‘I think we can’?” Sometimes the answer is “nothing, that’s my honest level of confidence and I’d ship anyway.” Sometimes it’s “remove this one story.” Either is a real answer; the silent vote is the trigger to find out which.

What to watch for:

Silent discomfort. Someone doesn’t object but their face says the plan is too much. The confidence check should have caught this; if it didn’t, ask directly, by name: “You’ve gone quiet. Which story are you worried about, and what would it take to remove the worry?”
“We’ll try.” Not automatically a no – a signal to ask one more question. “What would turn ‘we’ll try’ into ‘I think we can’?”
Scope-cutting inside stories. “We can do it if we skip the error handling.” No. Error handling is in the acceptance criteria or it isn’t. Cut scope by removing stories, never by cutting corners inside them.
The product owner negotiating down. The product owner offers to cut a story to reassure the team. Let them. This is the ritual working.

When everyone has said yes – genuinely said yes, not politely nodded – the sprint is committed. Write the commitment down with a date. The sprint starts.

See Sprint Planning: Turning Sticky Notes into Delivery for the Greenbox team running their first planning session – including the moment they discover that a sprint goal changes every single decision that follows it, and the moment one of the developers realises the commitment check exists precisely for people who were about to nod along with a plan they didn’t believe in.

What Can Go Wrong

The preparation session in disguise. Fifteen minutes debating what a story means, mid-planning. Recovery: “This story isn’t ready. Let’s pull it out of the sprint and work through it properly this week – maybe with Example Mapping – before it comes back to planning.” Stop if: Three stories in a row need that treatment. The top of the backlog isn’t ready for planning. End the session, schedule the preparation work, and come back.

The wish list. The product owner keeps adding “just one more.” Recovery: Hold the capacity number honest: “We’re at 24. This story is 5. Which 5-point story do you want to remove to make room?” Force the trade, every time. Stop if: The product owner won’t accept capacity as a constraint. That’s a systemic problem, not a session problem. Flag it to leadership outside the room.

The architecture debate. Developers start debating framework choices during task breakdown. Recovery: Park it: “Capture that as a design question. We need to know can we do it this sprint, not how.” Stop if: The debate is blocking task breakdown entirely. The story needs a time-boxed design investigation before it’s plannable; pull it.

The absent product owner. Product owner cancels the morning of. Recovery: Reschedule, same day if possible, next day if not. Stop if: This keeps happening. The ritual is broken; escalate the pattern, not the individual session.

The permanent over-commitment. Every sprint the team commits to 30 points and delivers 20, and nobody adjusts. Recovery: In the next planning session, write the last three sprints’ delivered totals on the board before story selection. Plan to the delivered number, not the committed one. Watch what happens. Stop if: The product owner insists on the committed number anyway. That’s a systemic trust problem; a planning session won’t solve it.

The silent veto. Commitment check passes, but one person clearly doesn’t believe it. They’ve said yes because saying no feels rude. Recovery: Take a break. Talk to them privately. Bring the concern back into the room as “There’s a worry about the migration story that I don’t think we surfaced properly – can we talk through it before committing?” so the objection is legitimised by the facilitator, not left to the quiet person to defend alone. Stop if: They still won’t speak. The team has a safety problem, not a planning problem.

The ritual collapsing into theatre. The sprint goal gets skipped and the sprint becomes a to-do list. Or carry-over isn’t counted against capacity and velocity quietly collapses. Or the commitment check becomes theatre and nobody actually believes the plan. Or task breakdown is skipped because “we know what to do,” and the team discovers mid-sprint that they didn’t. Or the session runs so long the team arrives at their first ticket exhausted. Recovery: Name the failure mode in the next retrospective. Pick one to fix. Don’t try to fix all five at once. Stop if: The retrospective itself can’t surface the problem – the ritual has fully collapsed and a planning session won’t rebuild it. Step back to first principles: what is this sprint for?

Next Steps

The session ends; the sprint begins.

Same day, the facilitator:

Sprint goal written where everyone can see it: team board, wiki, Slack topic, the top of the sprint in the tracker.
All selected stories moved into the sprint in the tracker, with tasks attached.
External dependencies communicated to the teams they touch, today, before the sprint starts.
Photograph the whiteboard if the task breakdown happened on physical sticky notes.

This sprint, the product owner:

This is where the pattern earns its cost, and the work is mostly the product owner’s.

Protect the sprint goal. Every “just one more thing” request that arrives this sprint gets measured against the goal. If it doesn’t serve the goal, it goes into the backlog for next sprint. If it does, it replaces something that doesn’t. The product owner is the only person who can make that trade.
Watch the burndown – the sprint’s day-by-day chart of remaining work – at the midpoint. For a two-week sprint, Thursday of week one. For a one-week sprint, the morning of day three. If you’re behind, have the conversation about what to cut now, not on the last day. The goal survives a scope cut; it doesn’t survive a last-day scramble.
Prepare the top of the backlog for the next planning session. This is the unglamorous work that makes next sprint’s planning an hour instead of three. Run Example Mapping on the candidate stories. Answer the red cards. Size the stories. Arrive at the next planning session with a backlog that is actually plannable.
Walk the goal to anyone who matters. Stakeholders, leadership, dependent teams. “Here’s what we’re doing this sprint and here’s why” said once at the start prevents five “what are you working on” interruptions mid-sprint.

Ongoing, the team:

Track velocity honestly. It’s the single most useful planning input and it only works if you measure what actually shipped, not what was committed.
If planning sessions consistently run long, the preparation happening before them needs work. Stories should arrive at planning ready to plan.
Retrospect on the planning session itself periodically. Is the goal still the contract? Is commitment still meaningful? Or has the ritual become theatre?

The pattern earns its cost across sprints, not within one. One hour per sprint week, every sprint, forever – that’s the price. A product owner who has to be available and prepared, a story-preparation process upstream that reliably produces ready stories, and the discipline to say no to “just one more” every single time – that’s what holds it up.

Variants

One-week sprint (default short cadence). One hour total, the four phases compressed. Task breakdown is tighter because the stories are smaller. Use when the team needs faster feedback loops or when scope volatility is high enough that two-week commitments break too often.

Two-week sprint (default long cadence). Two hours total, more room for goal pressure-testing and richer task breakdown. The default for most teams; one-week cadence costs more facilitation overhead per unit of delivery.

Distributed / remote. Same four phases on a Miro or Mural board. The silent confidence check transfers especially well to remote – everyone holds up fingers to camera at the same moment, no anchoring effect. Run the goal-setting conversation on video with the goal pinned at the top of the board for the rest of the session.

SRE / ops-heavy sprint. The goal looks like “Reduce deployment rollback rate from 1 in 5 to 1 in 20” or “Move the billing cron to the new scheduler with zero missed runs” rather than a user-facing capability. Capacity calculations include on-call load explicitly. Task breakdown often surfaces runbook updates and observability wiring as first-class tasks rather than afterthoughts.

First-sprint-with-this-team. Velocity is unknown, so capacity is a guess. Plan conservatively (commit to less than feels right), agree explicitly that the first two sprints are calibration, and use them to discover real velocity. Don’t pretend the guess is data.