Sprint Planning: A Complete Guide for Teams That Ship Every Week

Sprint planning is the meeting where a team turns a ranked backlog into a short commitment: a goal, a capacity number, and the tickets it will finish before the next cycle starts. A weekly team needs about an hour and should leave with work it can start on Monday. A weak session restates the backlog and leaves scope open until Thursday.

This guide covers who attends, what to prepare, how to set capacity and the goal, which work to take, and how to close.

What sprint planning is for

A sprint is a fixed window, often one or two weeks. The session answers three questions. What outcome will be true when it ends? How much time is left after meetings, support, and leave? Which tickets fit that time, in pull order?

The Scrum Guide calls this a timeboxed collaboration between the product owner and the developers, owned by the whole Scrum team. You don't need those titles for it to work. You need someone who can rank outcomes and a group who will do the work.

Leave estimation theatre, demos, and feature design out of the room. Spikes, customer calls, and refinement happen before the hour. If the top of the backlog is still a wish list, plan a smaller slice you understand.

Weekly teams versus two-week teams

A five-day sprint has little room for a ticket that "might" need a second pass. A two-week sprint can absorb one unknown. On a weekly team, each ticket needs a clear done state: a user-visible change, a reproduced bug, or an internal task with an owner.

Cap a one-week meeting at 60 minutes and a two-week meeting at 90. If it runs longer, the backlog usually wasn't ready, or the team is re-deciding strategy in the room.

Who comes, and what each person brings

The outcome owner (product manager, founder, or a tech lead wearing that hat) brings a ranked list and the reason the top items matter. Builders bring their availability, any dependencies, and a veto on tickets too vague to start. Support speaks once about a customer commitment, then leaves sizing to the builders. People who only follow the roadmap get the written plan afterwards. Every extra seat adds questions that won't change the commitment.

What "ready" means before you walk in

A ticket is ready when a builder can start without a second meeting:

• A one-sentence outcome instead of a task list.
• Acceptance checks a reviewer can apply without asking the author.
• Dependencies called out (API, design, access, a customer decision).
• A size the team believes, even "one day" rather than story points.

If more than a third of the candidates fail that test, start the meeting by cutting and clarifying.

An agenda that fits in one hour

Agile sprint planning fails when the agenda is "go through the backlog." Use the hour as laid out in A Sprint Planning Meeting Agenda That Fits in One Hour:

Minutes	Block	Output
0-5	Availability	Who is in, who is out, hours left after fixed meetings
5-15	Capacity	One number: builder-days the team will plan against
15-25	Goal	One sentence the team can repeat on day six
25-50	Select work	Ordered tickets that sum to capacity, with slack
50-60	Risks and close	Owners for blockers, the commitment read back

Start on time even if someone is late, because everything after availability depends on that first block.

The what, then the how

Scrum sprint planning often splits into "why and what," then "how." Agree on the goal and the candidates first. For the tickets you take, sketch the repo, the review path, and what is out of scope. Save the hour-by-hour breakdown for the day someone starts the ticket.

Points help the conversation, but the commitment is the ticket list and the goal. Hitting 28 points last sprint doesn't mean this week can hold 28 points of different work.

Set capacity before you pick tickets

Capacity is the number of focused days available for the planned backlog, and it is always less than headcount times five. Subtract holidays and leave, standing load (on-call, support, interviews, a release window), and an interrupt buffer. For a product team with live customers, 15-20% is a fair buffer. Even then, don't plan the remainder at 100%, because review, clarification, and failed CI are part of the work.

Write down one person-day number and stop renegotiating it ticket by ticket. If the number is 8 for three people, the work fits in 8. Plans like this fall apart on Wednesday because someone in the room added a ninth day.

A worked example

Four engineers. One is out Thursday and Friday (2 days). Support takes 0.5. Planning, standups, and review come to about 1 person-day. The interrupt buffer is 1.5.

4 × 5 = 20. After leave (2), support (0.5), meetings (1), and buffer (1.5), you plan against 15 person-days, or about 13 if the top tickets are unfamiliar. These are one team's figures, not a benchmark. Write the subtraction down before anyone starts championing a ticket.

Velocity can inform the buffer, but it shouldn't replace the calendar. Scrum velocity is a trailing average, and it tells you little when someone is on leave or the codebase is new.

Write the goal before the ticket list

A sprint goal is the outcome you'll still care about if half the tickets change. "Finish 12 tickets" doesn't qualify. "Merchants can refund a partial order without support" does. It should be one sentence, true or false at the end (so no "improve" or "continue"), small enough that two or three tickets could satisfy it, and visible outside the team.

To write a sprint goal people remember on day six, say it out loud, put it on the board, and check new requests against it. Work that doesn't serve the goal waits unless production is down. Some weeks the honest goal is operational: "Clear the error budget on checkout, no new features."

Choose the backlog, in order

Pull from the top. Re-rank only when there is new information, such as a customer deadline or a broken deploy. If you keep picking the easy tickets, the important one sits at position four forever.

For each candidate, ask four things. Do you understand what done looks like? Does it fit the days left? Does it serve the goal or a named must-fix? Who reviews it, so one person doesn't become the bottleneck? Stop when the next ticket would push you over capacity. Anything after that can go on an unordered "if we finish early" list that nobody promises.

The sprint backlog versus the product backlog is a scope line. The product backlog is everything you might do. The sprint backlog is what you said yes to for this window, plus the goal. Tickets move back when they no longer fit.

Estimation without wasting the hour

Use the lightest method that changes a decision. For many weekly teams, T-shirt sizes or a simple "fits in a day / does not" beat a full pointing round. Sprint poker is worth it when the team disagrees widely on a ticket big enough to blow the week. A one-line copy change doesn't need it.

If estimates split ("two days" versus "the whole sprint"), don't average them. Split the ticket or leave it out.

Risks, owners, and the close

Spend the last ten minutes on whatever would make the plan false: a dependency with no date, access or an environment that is still open, a ticket only one person can do while they also review everything else, or a deploy window you haven't booked.

Give each risk an owner. "The team will watch it" means nobody will. If a risk has no owner and no next step before Tuesday, drop the ticket that depends on it.

Read the commitment back in under a minute: goal, capacity, tickets, and what you left out. Silence counts as agreement. New ideas go to the product backlog, and the math stays closed.

During the week: the plan is a boundary

Plans fail more often in the five days after the sprint planning meeting than inside it.

Incidents jump the queue. Anything else is a trade: name the ticket that leaves, or the new work waits.

Unfinished tickets don't roll into next week's plan by default. If one still serves the goal, fits, and is unblocked, carry it. Otherwise split it or drop it. Falrow's cycles keep that review on the schedule, though a spreadsheet works too if you actually open it.

When tickets sit in review for three days, the plan is slipping. A Monte Carlo view of delivery won't promise a date, but it does show when the list has become fantasy. Make the cut on Tuesday.

A mid-week reset that takes 15 minutes

On Wednesday, compare finished work to the capacity you stated. If you're behind by more than the buffer, cut the lowest-ranked ticket that doesn't serve the goal, and announce it in the same channel as the commitment. Hoping Thursday will be twice as productive just means ending Friday with a pile of almost-done tickets.

Common failure modes

Assigning an owner to every ticket up front freezes the plan around vacations. Pull from a ranked backlog and name a specialist only where one is required.

A meeting used as refinement runs long. Timebox live clarification and drop anything still fuzzy after five minutes.

"If we have time" items end up reported as promised. Either they are in, with capacity to match, or they stay out of the update.

Pushed code is not done code. If review is late every week, the capacity number is too high.

Small teams sometimes copy a process built for a big room. PI planning in SAFe is worth borrowing for its shared goal and visible dependency list. You can leave the rest of the ceremony behind.

What to track so the next plan is better

In the last five minutes, note capacity planned versus the days you actually had, tickets finished versus carried, the interrupt that hurt most, and whether the goal came true. After a few weeks you'll see whether review was the bottleneck, the goal was too wide, or support ate the buffer. Then adjust the subtraction.

A template for capacity, the goal, and the commitment is all the layout you need. Teams coming from Jira often have sprints and points and still leave with a vague commitment. The gaps that show up in Jira are process gaps: no capacity line, no goal, and rollover done by dragging cards. A written capacity number fixes that. Switching tools doesn't.

A simple standard you can adopt this week

1. Publish capacity as person-days before selecting tickets.
2. Write one goal that is true or false on Friday.
3. Select work in rank order until you hit capacity, then stop.
4. Name a trade before any new ticket enters mid-week.
5. At the boundary, carry, split, or drop every unfinished ticket.

The sprint planning hour is where the team makes those five decisions together, out loud.

FAQ

How long should the meeting last?

Plan 60 minutes for a one-week sprint and 90 for a two-week sprint, assuming the top of the backlog is refined. If the meeting regularly runs long, the backlog isn't ready or the agenda has turned into a ticket tour. Fix refinement and keep the timebox.

What is the difference between sprint planning and backlog refinement?

Refinement makes tickets understandable: outcome, acceptance checks, dependencies, and a rough size. Planning chooses a goal and the subset of tickets that fits this cycle's capacity. Refinement can happen all week. The commitment happens once, at the start.

How many tickets should we commit to?

Commit to the person-days you calculated, not a ticket count. Five well-shaped tickets can fill a week, while fifteen tiny ones can hide a heavy review load. If you can't explain a ticket's size in one sentence, it isn't ready to count.

Who decides the sprint goal?

The person accountable for the outcome proposes it, and the people doing the work confirm it fits the capacity. If it doesn't, narrow it before you leave. A goal announced after the meeting is just a slogan.