Sprint Planning Structures

---

Origins

Sprint planning is one of the most-attended and least-loved Scrum events. The Scrum Guide¹ describes it briefly: the team plans what will be delivered and how, time-boxed proportional to sprint length. The brevity leaves teams free to invent their own structures, which they do — with widely varying degrees of success.

The structures described below all show up in real teams. None is universally right; each fits a different team maturity, work type, and stakeholder relationship.

Goal-First Planning

The Scrum Guide's recommended pattern. The session opens by setting the Sprint Goal — the single outcome the team is trying to deliver this sprint. The team then selects the backlog items that will achieve that goal, fitting capacity. Item-level discussion comes second; the goal anchors prioritization.

Strengths: keeps the team focused on outcomes; protects against the trap of "fill capacity with whatever's at the top." Sprint Review naturally focuses on whether the goal was achieved.

Weaknesses: requires the team to have a clear sense of what the goal could be before walking in. Teams without strong product direction struggle with this. Also doesn't fit operational or maintenance-heavy work where there isn't a coherent goal.

Capacity-First Planning

The team starts with available capacity (velocity, throughput, or person-days minus known interruptions) and pulls items from the top of the backlog until capacity is full. The goal emerges from the work that fits rather than driving the work selection.

Strengths: realistic about what the team can actually do; works for teams without coherent goal-shaped work; suits teams new to Scrum who don't yet trust their goal-setting skills.

Weaknesses: can produce sprints that feel directionless; sprint reviews become demos of unrelated items rather than reviews of an outcome. Drift toward "story factory" pattern.

Two-Part Planning

Scrum's traditional structure: Part One is "what will we do" (goal and items), Part Two is "how will we do it" (task breakdown, design discussion). The split lets stakeholders attend Part One for product input and leave before Part Two's engineering details.

Strengths: clean separation of concerns; protects engineering time from stakeholder distraction; stakeholders only attend what they need.

Weaknesses: feels formal; smaller teams find it overkill; the split makes the meeting longer rather than shorter for the team.

Swarm-Style Planning

The team commits to working as a mob or in pairs through the sprint, swarming items one at a time. Planning shifts from "who works on what" to "what's the first item we'll swarm and what does done look like?" Often combined with Mob Programming.

Strengths: fast planning — the team doesn't need to allocate items to individuals; whatever comes next is just "what's at the top." High collaboration; high knowledge spread.

Weaknesses: requires team comfortable with pairing/mobbing; some work doesn't suit swarm (independent investigations, individual specialist tasks).

Backlog Walk Planning

The team walks down the prioritized backlog one item at a time. For each: is this ready? Can we commit to it? Does it fit remaining capacity? Stop when capacity is full or no more items are ready.

Strengths: simple, mechanical, predictable; surfaces refinement gaps in real time.

Weaknesses: lacks goal coherence; can produce sprints that are random collections of top-priority items.

Continuous Planning / No Event

Some Kanban-leaning teams have effectively no planning event. The team pulls work as capacity opens; the prioritized backlog supplies the next item. Planning happens continuously through replenishment meetings rather than at sprint boundaries.

Strengths: zero overhead from planning meetings; matches flow-based delivery.

Weaknesses: requires very disciplined backlog; loses the rhythm of inspect-and-adapt that sprint boundaries provide; some teams need the cadence to stay coordinated.

Picking the Right Structure

The right structure depends on:

• Team maturity: new teams benefit from more structure; mature teams can do less.
• Work type: feature work suits goal-first; operational work suits capacity-first; cross-cutting changes suit swarm-style.
• Stakeholder engagement: high-engagement environments benefit from two-part to manage stakeholder attention.
• Refinement maturity: well-refined backlogs allow lighter planning; underrefined backlogs force planning to do refinement work.

Most teams should try multiple structures and choose what fits. Many teams discover their initial Scrum-textbook structure doesn't fit their actual context.

What Makes Any Planning Good

Independent of structure:

• Realistic capacity: based on history, not aspiration. Account for meetings, support work, expected interruptions.
• Clear acceptance: each committed item has explicit acceptance criteria.
• Identified risks: items that might not fit, dependencies that might slip, capacity that might shift.
• Sprint Goal articulated: even capacity-first planning benefits from naming the goal that emerges.
• Commitment from the team, not to the team: the team's commitment is to itself and the product, not imposed from outside.

Common Pitfalls

• Planning as commitment ceremony: stakeholders attend to extract commitments rather than the team deciding what to commit to.
• Overcommitment: ignoring history and packing the sprint full. Predictable failure followed by retro complaints.
• Underrefined backlog: planning becomes refinement, takes hours, produces shallow commitments.
• No Sprint Goal: even capacity-first should produce a coherent narrative. "Random items" sprints are hard to review meaningfully.
• Same structure forever: a team that started with two-part Scrum planning four years ago has probably outgrown it. Revisit periodically.
• Planning theater: going through motions because Scrum says so, when the team would benefit from a different structure entirely.

Coaching Tips

Match Structure to Context

Goal-first for feature work; capacity-first for operational; swarm-style for collaborative teams. Don't force one structure on all situations.

Use Real Capacity

Velocity averaged across recent sprints, minus known interruptions. Aspirational capacity produces predictable overcommitment.

Articulate the Goal

Even capacity-first planning benefits from naming the emerging goal. "We're shipping X and improving Y" gives the sprint meaning.

Refine Before Planning

If planning becomes refinement, the meeting will run hours. Insist on refinement before sprint planning so planning can stay short.

Protect the Team's Commitment

Commitments belong to the team. Stakeholders shouldn't pressure-load the sprint or extract promises the team didn't make.

Evolve the Structure

The structure that worked at team formation may not fit two years in. Use retros to evaluate planning effectiveness and adjust deliberately.

Summary

Sprint planning's shape is not fixed in Scrum. The Scrum Guide describes the event briefly enough that teams have significant freedom in how they run it. The structure that works depends on team maturity, the kind of work, the stakeholder context, and the team's refinement discipline.

The honest answer for most teams is to try several structures and adopt what fits. The textbook two-part Scrum planning isn't the best fit for every team; capacity-first works well for some; swarm-style suits teams that have invested in pairing; continuous planning works for flow-based teams. The discipline is choosing deliberately, then evaluating in retros whether the structure is producing the planning outcomes the team needs.

Back to Agile Delivery