Sprint planning has a reputation problem. Ask any engineer what they think of it and you will hear the same story: three hours in a call, forty minutes arguing whether a ticket is a 3 or a 5, and a sprint that is already stale by Wednesday.
None of that is inherent to planning. It is the symptom of doing three different jobs — backlog cleanup, estimation, and commitment — in one meeting. Split them apart and the meeting itself collapses to half an hour.
Why planning meetings balloon
Three patterns show up in almost every slow planning session:
- The backlog is groomed live. Half the meeting is spent reading tickets aloud for the first time. If an issue needs a description, acceptance criteria or a decision, that work happens before planning, not during it.
- Estimation becomes theater. Long debates about story points rarely change what actually gets built. The useful signal is "small / normal / scary", and a scary ticket means "split it", not "argue about it".
- Nobody owns the goal. Without a single sprint goal, planning defaults to "fill the capacity bar" — and a bag of unrelated tickets is much harder to agree on than one outcome.
The 30-minute agenda
Here is the agenda we use internally, timed:
| Minutes | Step |
|---|---|
| 0–5 | Restate the sprint goal. One sentence, written down. |
| 5–10 | Review carry-over: finish, split or drop — no re-estimating. |
| 10–25 | Pull candidate issues against the goal, top-down. Small/normal/scary only. |
| 25–30 | Capacity sanity check, confirm, start the sprint. |
The prerequisite is a ready backlog: every candidate issue already has a clear description, an assignee guess and a rough size before the meeting. That preparation is asynchronous — ten minutes per person, done during the week, instead of an hour of everyone's time in a call.
Running it keyboard-first in your.team
This agenda maps directly onto Sprints in your.team:
- Goal first. The sprint goal field sits at the top of the sprint — write it before you invite anyone. Velocity from the last three sprints is shown next to it, so the capacity conversation is a glance, not a spreadsheet.
- One keystroke to commit. Move an issue to the sprint from the backlog with a single keystroke — no drag, no dialog. Working top-down through a ranked backlog takes minutes.
- Boards stay honest. Committed work lands on the board with WIP limits, so overcommitting is visible on day one, not in the retro.
- Carry-over is explicit. When you complete a sprint, unfinished issues are moved deliberately — nothing silently rolls forward, which is what keeps sprint two honest.
- Estimation without theater. Hours attach to every card, and ETracking fills in actuals while a task timer runs. After a few sprints you compare estimated vs. real time in Reports — and your "small/normal/scary" gut gets calibrated by data instead of debate.
If the planning conversation needs to happen face to face, spin up a meeting directly from the sprint — the context travels with the call, so nobody screen-shares a backlog.
What to drop entirely
- Planning poker for everything. Reserve real estimation effort for the two or three genuinely uncertain tickets. Everything else is a size label.
- Reading tickets aloud. If a ticket cannot be understood by reading it, it goes back to the backlog — that is a writing problem, not a meeting problem.
- Committing to the capacity number. Commit to the goal. The capacity number is a guardrail, not a target to fill.
The test
A sprint planning meeting has exactly one deliverable: a started sprint with a goal the team believes in. If your meeting produces that in 30 minutes, everything else — grooming, estimating, debating — has found its proper home outside the call.
Try the agenda on your next sprint. If you want the tooling side of it, Sprints is included on every your.team plan, free included.