Guide
How to Run Sprint Planning
A lightweight, capacity-honest sprint planning process teams actually keep - refine early, plan against real capacity, commit to a goal, and close the loop with data.
Sprint planning fails in the same predictable ways: the backlog isn't actually ready, the team plans for a fantasy version of itself that has no meetings and no interruptions, and estimates get treated as promises. The result is a plan nobody believes by Wednesday. A good process fixes all three by front-loading refinement, planning against real capacity, and treating the sprint goal - not the ticket count - as the thing you commit to.
This guide describes a lightweight, capacity-honest process teams actually keep. It assumes a ranked backlog exists, work items have acceptance criteria, and you can look back at how much the team truly delivered last sprint. The whole meeting should take 30 to 60 minutes for a team of five to eight. If it routinely runs longer, the problem is almost always unrefined work entering the room - fix that upstream, not by planning harder.
The mindset shift that matters most: you are not trying to fill every available hour. You are trying to pick the smallest set of work that achieves a clear goal and can absorb the surprises every sprint delivers. Planning to 100% capacity guarantees a miss.
1. Refine the backlog before the meeting, not during it
The single biggest cause of long, chaotic planning is unrefined work. Hold a short refinement session mid-sprint so the top of the backlog is always "ready": each item has clear acceptance criteria, no unanswered questions, and a rough size. Planning is for selection, not discovery.
- Define "ready" explicitly - for example, criteria written, dependencies known, design attached if needed.
- Only items at the top of the ranked backlog need to be ready; don't refine the whole thing.
- If an item spawns big open questions in planning, pull it out and spike it - don't stall the room.
If you struggle to write crisp criteria, our acceptance criteria grader and the product plan guide can help tighten the inputs.
2. Calculate real capacity, not headcount × days
Capacity is the number of person-days you'll actually spend building sprint work - after subtracting the things that reliably eat time. Start from calendar days and remove them honestly:
- Time off and holidays - PTO, public holidays, on-call rotations.
- Meetings and ceremonies - standups, reviews, planning, 1:1s.
- Interrupt load - support, incidents, code review for others.
- A buffer - reserve 15-25% for the unknown. It always shows up.
Most teams end up planning to roughly 60-70% of raw headcount. That's not slack - it's the truth. Use the sprint capacity planner to model it per person, and look at your delivery data to see how much you really shipped last sprint rather than guessing.
3. Set one clear sprint goal
Before you pick tickets, agree on why this sprint exists. A sprint goal is a single sentence describing the outcome - "ship self-serve password reset" or "cut checkout p95 latency below 400ms" - not a list of tickets.
- The goal is what you commit to; individual tickets are the current best plan to get there.
- It gives you a decision rule mid-sprint: if a new ask doesn't serve the goal, it waits.
- If you can't state one coherent goal, that's a signal the sprint is a grab-bag - worth a conversation with the product owner.
4. Select work against the goal and the capacity number
Pull from the top of the ranked backlog, choosing the items that most directly advance the goal, and stop when the estimated work fills your real capacity - not the raw one. Selection, not negotiation.
- Take items top-down; if you're reaching past the goal to fill hours, stop instead.
- Every item should already have acceptance criteria (Step 1). If it doesn't, it isn't ready.
- Leave the buffer unfilled on purpose. It's for the incident, the flaky test, the review that turns into a rewrite.
- Prefer finishing fewer things to starting more. Throughput comes from limiting work in progress, not from a fuller board.
5. Estimate to expose risk, not to make promises
Estimates exist to surface disagreement and hidden complexity, not to lock in a delivery date. When two people size the same item very differently, the conversation that follows is the real value.
- Use relative sizing (story points or t-shirt sizes) or simple ideal-hours - pick one and stay consistent.
- Try planning poker to estimate independently and reveal spread; discuss outliers.
- Split anything larger than a couple of days. Big items hide risk and clog the board.
- Never turn a point total into a headline commitment. You commit to the goal (Step 3), not the number.
6. Confirm the commitment and name the risks out loud
Close the loop before people leave the room. Read the goal back, walk the selected items, and ask the team plainly: "Do we believe we can deliver this?" A quiet room is not a yes.
- Assign clear first owners so nothing starts as "someone's."
- List known risks and dependencies explicitly - the external API, the review from another team, the environment that's flaky.
- Agree on the rule for mid-sprint arrivals: does it serve the goal, and what gets dropped if it comes in?
7. Close the loop with data at retro
A process only stays honest if you measure whether the plan matched reality. At the end of the sprint, compare committed vs. completed, and look at flow, not just output.
- Track cycle time and where items stall - long review or QA waits mean the bottleneck isn't planning.
- Feed the delivered amount back into next sprint's capacity number so it self-corrects.
- Watch DORA metrics over time to confirm the pace is sustainable, not borrowed from future sprints.
FeatureFactory's engineering metrics and DORA tracking connect the plan to what actually shipped, so planning improves each cycle instead of repeating the same optimistic miss.