Most sprint planning meetings run too long, generate too little useful output, and leave the team uncertain whether the sprint is committable. The reason is almost always agenda design — not the people, not the team, not the work.
Below is the agenda we recommend. 60 minutes for a 2-week sprint. Everything timed. Five things you should skip.
The 60-minute agenda (2-week sprint)
0–5 min: Sprint goal stated, written down, agreed
The lead opens with a one-sentence sprint goal. The team has 4 minutes to push back on wording. By minute 5, the goal is final and pasted at the top of the planning doc.
If the team can’t agree on a goal in 5 minutes, that’s a sign — not of bad people, but of bad pre-work. Stop the meeting, take an hour offline, come back.
The goal sounds like:
“Customers can complete the new checkout flow without errors on web and mobile.”
Not:
“Ship checkout v2.”
The first is testable; the second is a deliverable label.
5–15 min: Capacity check
The lead reads a list of who’s on PTO, who’s on call, who’s working on cross-cutting items, and how many person-days are realistically available for sprint work.
Use a calculator if it helps — we have a free Sprint Capacity Calculator — but the conversation is what matters. Capacity check should produce a single number (“we have 38 person-days, ~25 story points realistic”) that the team agrees on before discussing tickets.
If capacity is significantly less than last sprint, name it. Don’t pretend.
15–45 min: Walk the candidate backlog
The team walks through 6–10 candidate tickets the lead pre-selected. For each:
- 30 seconds: lead reads ticket aloud, surfaces acceptance criteria
- 60–90 seconds: team estimates (Fibonacci 1/2/3/5/8). Flag 13+ → break it down or spike it.
- 30 seconds: assign owner if obvious, otherwise leave open
This is the bulk of planning. 6–10 tickets in 30 minutes means ~3 minutes per ticket. If a ticket takes longer than 5 minutes, defer it — there’s information missing that won’t be resolved by talking.
45–55 min: Commit
The team looks at the running total of points. Compares to capacity. Cuts the lowest-priority items until the commit fits. The sprint goal stays — what gets cut is supplementary work.
The lead asks, explicitly: “Are we comfortable committing to this?”
If anyone hedges, dig in. A “yes” with reservations is a known anti-pattern that produces sprints with 30% spillover.
55–60 min: Risks and dependencies
Before closing: any external blockers? Anything the team is waiting on that could block the sprint? Surface them now, not on day 7.
Common items:
- “Customer X needs to provide credentials before we can test the integration”
- “Design hasn’t finalised the empty state for the new flow”
- “Backend ticket Y blocks frontend ticket Z — make sure Y starts day 1”
Close meeting at 60. Don’t run over.
Why 60 minutes?
Two-hour sprint planning is the most common bug in agile literature. Most teams have it because their lead hasn’t pre-selected the candidate backlog. The team improvises ticket selection during the meeting itself — which means 80% of the time is reading tickets and arguing over acceptance criteria.
That work belongs out of the meeting. The lead spends 30–60 minutes the day before planning to:
- Order the backlog by priority
- Pick 8–12 candidate tickets that fit the sprint goal
- Confirm acceptance criteria are written for each
- Flag anything that needs re-scoping
If that prep happens, 60 minutes is plenty. If it doesn’t, no amount of meeting time is enough.
Five things to skip
Skip: re-explaining the previous sprint
This is what your retrospective is for. Don’t relitigate last sprint in planning. If something specific from last sprint blocks this sprint, name it in the risks section (last 5 minutes), don’t recap.
Skip: planning poker rounds with extensive debate
Estimates are calibrations, not contracts. If two people estimate 3 and 8 on the same ticket, they have different models — but a 30-minute discussion rarely converges them. Average to 5, move on, let the data calibrate over sprints.
The exception: if the disagreement is about scope (one person thinks the ticket means X, another thinks Y), stop and clarify acceptance criteria. That’s worth time. Pure estimation disagreement isn’t.
Skip: assigning every ticket in the meeting
For 5-person teams, leaving 2–3 tickets unowned at planning is fine. People grab them in standup as work progresses. Forcing assignment in planning often produces wrong assignments based on who’s vocal in the meeting, not who’s available.
Skip: discussion of tickets you can’t ship this sprint
Tickets bigger than the sprint should be broken down before planning, not in it. If a 13-pointer slips into the candidate list, the lead should have already noted “this is a spike, not deliverable in this sprint.” Don’t discuss it in planning beyond “we’ll spike this.”
Skip: status updates from individuals
This is what standup is for. Planning is forward-facing. The only individual status that belongs is “I’m at half capacity this sprint” — and that’s part of capacity check, not a separate slot.
The pre-planning prep that makes this work
The agenda above only fits in 60 minutes if the lead has done 30 minutes of prep the day before. Specifically:
1. Backlog ordered. Top 12 items in priority order, with a clean break between “in this sprint” and “below the line.”
2. Acceptance criteria written. Every candidate ticket has clear AC. Not “make checkout work” — “user can submit, sees success state, receives email confirmation.”
3. Sprint goal drafted. Lead writes a candidate goal, pastes it in the planning doc, asks the team to react in advance via Slack thread or async comment. By the meeting, the goal is 80% formed.
4. Risks anticipated. Lead has a one-line list of “things that might block us this sprint.” Doesn’t have to be exhaustive.
5. Calendar checked. Who’s on PTO, who’s on call, who has unavoidable conflicts. This is just calendar work.
If those five prep items happen, planning is fast and effective. If they don’t, the team improvises in the meeting and the meeting balloons.
What the planning output should be
By the end of 60 minutes, you should have a single planning doc with:
- The sprint goal (one sentence)
- Capacity number (e.g., “38 person-days, 25 story points”)
- Committed tickets (with points, owners where assigned)
- Risks list (3–5 items)
- Anything explicitly out-of-scope this sprint
Paste it in your sprint tool. Pin it in Slack. Reference it in standup (“are we still on track for the goal?”). It’s the source of truth for the next 10 working days.
Common failure modes (and the fix for each)
Sprint balloons mid-meeting (“let’s add this one more thing”): the goal isn’t tight enough. Re-read the goal, ask “does this advance the goal?” If not, defer.
Estimates drift up across the meeting: usually a sign capacity is over-stretched. Stop, look at the running total, recalibrate.
Same ticket comes back every sprint: the work is unclear, the AC is wrong, or the priority isn’t real. Pull it from the backlog and either rewrite or kill it.
The team hedges on commit: ask explicitly what’s making them hedge. Almost always one specific ticket that’s too vague. Cut it or break it down.
Planning ran over by 30 min: prep wasn’t done. Don’t fix it in the meeting; fix the prep next sprint.
Tools, not magic
There’s nothing magic about this agenda. We’ve seen teams run effective planning in 30 minutes with great prep, and ineffective planning in 3 hours with bad prep. The agenda is just structure that forces the prep to matter.
Want a copyable template? Our Sprint Planning Meeting Template has this agenda in markdown form — drop it in your tool of choice. We also have a Sprint Goal Canvas for drafting the goal beforehand.
The one rule
Planning ends on time. That’s the discipline. Not on the dot, but within 5 minutes of the slot. A planning meeting that runs over by 30 minutes every sprint is a meeting that’s signalling — every time — that the team isn’t ready to commit. Address the readiness, not the meeting length.
The 60 minutes is plenty. Make it count.
SprintFlint is built for engineering teams running real sprints — capacity-aware planning, story-point velocity, native retros, and MCP integrations for Cursor / Claude Code / Copilot. £5/user/month flat. Start free — 300 tickets, no card.