Sprint Planning 101: How to Plan a Cycle That Ships

TL;DR: Sprint planning has one job: produce a plan the team actually believes. That takes five steps. Face last cycle's facts, count capacity honestly (maintenance and interrupts eat far more than plans admit), set one goal, pull work until your trailing throughput says stop, and ready-check everything you commit. Plans fail for arithmetic reasons: oversized items, fictional capacity, silent mid-cycle intake, and review queues. Track carryover and scope-added-mid-cycle, and let history size the next cycle.

Sprint planning (cycle planning, iteration planning, the ritual is the same) is the most rescheduled, least respected meeting in engineering, and it earns that by producing plans nobody believes. The team nods at fourteen items, privately expects to finish eight, finishes seven, carries the rest, and repeats. More ceremony won't fix that. Treat planning as what it actually is, a forecast, built the way honest forecasts are built: from history, with slack, in small batches.

What is sprint planning actually for?

Two decisions, nothing else:

1. What is the most valuable work to do next cycle? (Priority.)
2. How much of it fits? (Capacity.)

Everything else is optional and usually inflationary: estimation rituals, points debates, roadmap therapy. The output is a short list the team genuinely expects to finish, plus one sentence of intent: the cycle goal. If your planning regularly produces a list the team privately discounts, the meeting is generating fiction, and every downstream artifact inherits it - the burndown, the stakeholder update, the date you gave the CEO.

How long should sprint planning take?

For a two-week cycle: 60-90 minutes, if the backlog arrives groomed. If planning routinely runs three hours, the meeting is doing refinement's job - writing the tickets in the room instead of checking them. Split it: refinement happens asynchronously or in a short mid-cycle session; planning only confirms, sizes against capacity, and commits.

The agenda, step by step

1. Face last cycle's facts (10 min). Before planning anything: what did we plan, what did we finish, what carried over, what arrived unplanned? This is the accountability loop, and it's the same data your delivery tracking already captures. Chronic carryover isn't a moral failing. It's the forecast being wrong in the same direction every time, which is the most fixable kind of wrong.

2. Count capacity honestly (10 min). List who's actually here (holidays, on-call, the conference), then subtract the standing tax. This is where most plans die, because plans assume clean hours and reality doesn't have any. In Stripe's Developer Coefficient survey (1,000+ developers, self-reported), developers reported an average 41.1-hour week with 17.3 hours going to maintenance work: bad code, debugging, refactoring. Nearly half the week, before a single roadmap item. Interruptions compound it. Parnin & Rugaber's study of 10,000+ programming sessions found only ~10% of sessions resume editing within a minute of an interruption, and ~30% take over half an hour. Your capacity is not headcount × hours. Plan for the half of the week that's really available, and call that realism.

3. State the cycle goal (5 min). One sentence, outcome-shaped: "checkout latency work shipped and measured," not "do the tickets." The goal is the tiebreaker for every mid-cycle decision and the honest thing you report at the end.

4. Pull work until throughput says stop (30 min). In priority order, one item at a time, against your trailing throughput: the count of items the team actually finished in each of the last several cycles. Yesterday's weather beats estimation debates. If history says nine to twelve items, planning eighteen isn't ambition, it's a decision to disappoint. Use the median, and know your bad-cycle number too. Velocity works fine here, as a planning input for this team's next cycle, which is the one job it can honestly do. Keep the batches small while you're at it: a decade of DORA research finds strong performers work in small batches with fast feedback, and LinearB's benchmarks put elite PR size under 100 changed lines. An item that can't produce small PRs is telling you it's too big for the cycle.

5. Ready-check what you commit (10 min). Every item passes or leaves:

• Problem and acceptance criteria stated; "done" fits in one sentence
• Sized small enough to finish within the cycle, with room to spare
• No unresolved external dependency ("waiting on the API team" is not a plan)
• A named first step

6. Leave visible slack. Unplanned work arrives every cycle whether you budget for it or not. Budgeted, it displaces nothing; unbudgeted, it displaces the goal. A plan at 100% capacity is a queue at 100% utilization, and queueing math is brutal about what that does to wait times.

Why plans fail: arithmetic, not effort

When the cycle ends short, the retro reflex is "estimate better." Usually wrong. Check these first, in order:

• Carryover share. Chronically above a quarter of the plan ⇒ the plan is oversized. Shrink it. (Yes, it will feel like admitting something. It's admitting arithmetic.)
• Scope added mid-cycle. Silent intake is invisible precisely because nobody planned it: the Slack DM that becomes a ticket that becomes the sprint. Count it; it's often the entire gap, and it's a board-hygiene problem before it's a planning problem.
• Items too big. Anything that spans a whole cycle will span more than one. Split until items finish in days.
• The queue after "code complete." Work that's done-but-waiting isn't done. If finished PRs wait days for review, the pipeline failed, and no amount of estimation fixes a pickup queue.
• Padding. Doubling estimates doesn't help, because elapsed time is dominated by waiting, not working. Padding the work estimate doesn't touch the queues where the time actually goes.

How to know planning worked

Three numbers, reviewed next planning and brought to retro when they drift: carryover share (did planned mean finished?), scope added mid-cycle (did the plan survive contact?), and goal hit (did the sentence come true?). When "planned" predicts "done" three cycles running, your planning is working. Your stakeholder communication upgrades automatically too, because now it's built on a forecast with a track record.

Where Busfactor fits

Every input this guide asks for is something Busfactor computes from your actual history, so here's the explicit pitch. Trailing throughput isn't a number someone assembles before the meeting. The delivery forecast card divides open scope by your org's own weekly throughput percentiles and shows the p50-p90 range over the real weekly bars, method disclosed on the card, deterministic, no Monte-Carlo black box. When your slowest weeks ship zero, it says "not at this pace" instead of inventing a date. The ticket-hygiene surface catches silent intake, zombie tickets, board-vs-git drift, and estimate-vs-reality gaps - the exact leaks that make carryover chronic. Cycle-time anatomy shows whether the plan died in coding or in the queues after it. And ticket loops flag the items that keep bouncing back from Done, which are your "too big / never ready" candidates with receipts attached.

The honest limits: Busfactor doesn't run the meeting, pick your priorities, or know that half the team is at a wedding next Thursday. Capacity judgment stays human. Its ticket-side numbers are only as good as your board (it will tell you when the board is lying, but it can't read minds). What it removes is the hour of archaeology before planning and the fiction after it. The history is on screen, judged, with the PRs and tickets linked, so the argument can be about what to build instead of about what happened.