A Sprint Planning Meeting Agenda That Fits in One Hour

A sprint planning meeting agenda that fits in one hour has five blocks: confirm capacity (10 minutes), agree the sprint goal (10), select and slice work (25), name risks and dependencies (10), and say the commitment out loud (5). Anything else belongs in refinement. You want a shared yes to this goal, this set of tickets and this capacity, starting tomorrow.

A one-hour sprint planning meeting agenda

Put a timer where everyone can see it. The facilitator owns the clock and should not be defending every ticket. The product owner owns priority. The people doing the work decide whether the set fits.

Block	Minutes	Owner	Done when
Capacity	0-10	Team lead	A number of person-days everyone accepts
Sprint goal	10-20	Product owner	One sentence the team can repeat
Select and slice	20-45	Whole team	An ordered list that fits the number
Risks	45-55	Whole team	Each risk has an owner, or the item is cut
Commitment	55-60	Facilitator	Someone restates the goal and the list

If a block finishes early, close it. Don't spend spare minutes on debate. Time left at minute 55 is what gets you out on time.

This sprint planning meeting agenda assumes a refined backlog. A story that still needs a design decision, an acceptance note or a legal conversation isn't ready. Pull the next ready item and send that one back. Negotiating scope inside a fuzzy ticket is how the hour becomes 90 minutes with no goal.

What a sprint planning agenda is for

A sprint planning agenda limits the meeting more than it scripts it. It answers the three questions in the Scrum Guide: why this sprint is valuable, what can be done, and how the chosen work will get done. One hour is enough when you already have evidence for the first two. Break tasks down afterward, on the tickets. Status belongs in the daily. You pick a small set of outcomes and turn the rest down until the next cycle.

The agenda for sprint planning, block by block

Minutes 0-10: capacity before desire

Holidays, on-call, interviews, a launch already in flight and incoming support shrink the sprint before the backlog opens. Write the number in view. Six people, one out for three days, plus shared on-call, are not six people's capacity.

Use last sprint's finished work as a sanity check. Don't treat it as a target. Scrum velocity is a range for similar conditions, and it says nothing about unfamiliar work.

On the board: six engineers, ten working days, minus three days of leave and four of on-call and interviews. About 53 engineer-days on paper. Hold back about a fifth for bugs and review. Planning number: about four focused people.

Minutes 10-20: one sprint goal

The product owner brings one outcome, drafted beforehand. The team edits it until they'd bet on it. Name the user and the change they'll notice. "Improve performance" is a theme. "Checkout on mobile completes without a second payment retry for the three most common card errors" is a goal.

If there are two competing goals, pick one. The other waits; otherwise you've just scheduled Thursday's argument. For a sentence that still holds on day six, see how to write a sprint goal.

Minutes 20-45: select, then slice

Pull from the top of a ready backlog. Does it serve the goal, and does it fit what's left? If not, it waits, even when small.

Stay at story level: rough size, riskiest unknown, dependency. Use planning poker only when sizes disagree, two minutes a round. If it still can't be sized, it isn't ready, so park it.

Slice an oversized story on a line a user can see. "Error copy for the three card failures, retry button later" is a slice. "Backend now, UI later" usually isn't, because nothing is acceptable at the cut.

Order so the top completes the goal if you finish only half. That is the difference between a sprint backlog and a product backlog: the committed slice, versus the longer list you didn't pick.

Stop when the number is full. Teams miss sprints by squeezing in "one more," so put it under "next" instead.

Minutes 45-55: risks and dependencies

Walk the list once. What could block an item from outside the team: another squad's review, a vendor sandbox, a feature-flag default, a migration window, copy legal hasn't seen. Each risk gets an owner and a date inside the sprint, or the item comes off. Name it and move on; the solving happens outside the room. If availability changed during the meeting, fix capacity before anyone commits.

Minutes 55-60: say the commitment

The facilitator reads the goal and the count. Someone doing the work says it back: "Checkout error rewrite for three card failures. Eight stories. Retry button out."

Silence doesn't count as a yes. Cut scope until they can say it. A no at minute 58 beats a quiet no on day four. Put the goal in the board header or channel topic, or the first interruption erases it.

A worked example: six people, one hour

A payments team plans two weeks around failed mobile checkouts from three card errors.

Capacity (8 minutes). One engineer out three days, on-call about three days last sprint. Planning number: 45 engineer-days, support included.

Goal (9 minutes). Retry button out. "A shopper who hits one of the three card errors sees a specific next step and finishes checkout without chat." Copy is already on the ticket.

Select (23 minutes). Visa and Mastercard only, since they're most of the volume. A logging tidy-up stays off. A two-minute round finds an unlogged gateway response, so a one-day spike goes on top and the last cosmetic story comes off.

Risks (8 minutes). The sandbox expires Wednesday; one engineer renews it before Monday noon. Legal already signed the copy.

Commitment (4 minutes). Seven stories plus the spike. Other brands and the retry button are out, said aloud. Done at 59.

Prepare this the day before

The product owner shares four things:

1. A proposed sprint goal in one sentence.
2. A ranked shortlist longer than you need, refined, with acceptance notes a new teammate could test.
3. A draft capacity line, including known absences.
4. Known dependencies, so minute 45 confirms them.

If that shortlist isn't ready, cancel and refine. "What should we even consider?" will not end in a commitment.

After the meeting, keep the same cuts

Read the goal before a ticket. If it doesn't move that sentence, it's an interruption or next sprint. Past the holdback, cut from the bottom that day and say so in the daily.

A bottom third that always slips means the number is too high. A top third that slips means the work wasn't sliced. Note which block ran long and fix that one next time. Unreviewed rollover hides a miss, so put unfinished work back only if it still serves the new goal. Sprint planning is the wider practice. This hour is where that decision gets made, every cycle.

Any board works with capacity, the goal, the ordered list and named risks. Falrow keeps the decision on a cycle, with reviewed rollover so unfinished work can't slip forward unnoticed, and cycle time and a Monte Carlo forecast next to recent history. A doc and a timer already beat a session that never reaches a yes. Other tools work if you keep the five blocks.

FAQ

How long should a sprint planning meeting be?

One hour fits about three to eight people on a one- or two-week sprint with a refined backlog. An unrefined backlog won't fit, and a second hour rarely fixes it. Refine earlier, or shorten the sprint. The Scrum Guide's eight hours is a ceiling for a one-month sprint. Weekly teams need far less.

Who should attend sprint planning?

The people doing the work, the product owner and a facilitator. Stakeholders may hear the goal and the commitment, but they don't add scope in the room. Design and QA count when their time is in the capacity number. A dependency owner comes for the risk block only.

What if the team cannot agree on a sprint goal?

Cut the shortlist until one sentence is true, or stop and refine. Two goals joined by "and" are really two projects. Starting without an agreed goal moves the argument into the daily, where it costs more.

How is sprint planning different from backlog refinement?

Refinement makes a ticket ready: outcome, acceptance notes, a trusted size, named dependencies. Sprint planning picks a subset that fits capacity and one goal. Working out what a ticket means is still refinement, and the planning clock shouldn't be running. Mixing the two is why the hour runs over.