Sprint planning: how to plan a sprint your team can finish

9 October 2026 · 7 min read

A good sprint planning meeting ends with a goal everyone can repeat and a plan the team believes in. A bad one ends with an overfilled board and a sprint that is lost before it starts. Here is how to prepare, how to size the sprint to your team's real capacity, and an agenda you can use in your next session.

What sprint planning is for

Sprint planning opens every sprint in Scrum. The whole Scrum team takes part: the product owner, the developers and the Scrum Master. Together they answer three questions:

1. Why is this sprint valuable? The product owner explains what would make the sprint worthwhile, and the team turns that into a sprint goal.
2. What can be done this sprint? The developers pick backlog items that serve the goal and that fit in the time they actually have.
3. How will the work get done? The developers break the chosen items into smaller steps, often a day of work or less.

The goal, the chosen items and the plan together make up the sprint backlog. The meeting is timeboxed: at most eight hours for a one-month sprint, and less for shorter sprints. Most teams running two-week sprints need about two hours once they get into a rhythm.

Prepare before the meeting

Most long, painful planning meetings are really refinement sessions in disguise. If the team sees a story for the first time in planning, it has to understand, discuss and estimate it on the spot. Do that work earlier, in backlog refinement:

• Order the backlog. The product owner puts the most valuable items at the top, so planning never starts with "what should we do?".
• Make the top stories ready. Each has a clear description and acceptance criteria, and its dependencies are known. Aim for roughly one to two sprints of ready work.
• Estimate in advance. Size the top of the backlog in refinement with planning poker, so planning only needs to estimate the odd new or changed story.
• Collect availability. Ask about holidays, training, on-call duty and public holidays before the meeting, not during it.

Start with the sprint goal

A sprint goal is one or two sentences that say what the sprint will achieve, for example "Customers can pay by bank transfer" rather than "Finish PAY-112, PAY-115 and PAY-120". The goal gives the sprint a focus. When something unexpected comes up halfway through, the team can ask whether it helps the goal, and can renegotiate the details of the work without losing the outcome.

The product owner usually brings a proposal, and the whole team shapes it. If no sensible goal fits the top of the backlog, the backlog probably needs reordering.

Work out your capacity

Capacity is how much work the team can realistically take on this sprint. It starts with your velocity, the story points the team has completed in recent sprints. Then adjust it for who is actually around. Our guide to story points and velocity explains averages and forecast ranges in more depth. Here is the short version.

Take a team of five on a two-week sprint (10 working days each, so 50 person-days). The team's average velocity over the last few sprints is 30 points.

The team has 86% of its usual time, so plan for about 30 × 0.86 ≈ 26 points. Then leave room for the unexpected: support requests, bugs and reviews never appear on the board. Commit to about 80% of that, roughly 21 points, and keep one or two more ready stories as stretch work to pull in if the sprint goes well.

New teams have no velocity yet. Make an honest first guess, keep the first sprint light, and use what you actually finish as your starting velocity.

Choose the work

With a goal and a capacity, selecting the work is mostly mechanical. Walk down the ordered backlog and, for each story, check three things:

• Does it serve the sprint goal? If not, does it still belong in this sprint?
• Is it ready? If the team can't explain what "done" looks like, it isn't ready. Don't pull it in hoping to work it out later.
• Is it estimated? If not, estimate it now. Planning poker takes a minute or two per story when everyone votes at once.

Stop adding stories when the total reaches your capacity, even if the next story looks small. The developers decide how much they can take on, not the product owner or a manager. A plan the team doesn't believe in is not a commitment.

Plan how to do it

For each chosen story, the developers sketch the steps: the changes to make, the tests, the reviews and anything else your definition of done requires. This is where hidden work surfaces. A migration needs a maintenance window, or a design isn't finished yet, or a story needs another team's API.

Don't plan every task in detail. Break down the first few days carefully and leave later stories coarser; the team will learn things as it goes. If a story turns out to be much larger than its estimate, split it now, or swap it for something smaller before the sprint starts.

A sample agenda for a two-week sprint

For the confidence check, ask everyone to rate their confidence in the plan from one to five, all at the same moment. Anything below a three is worth a short conversation before you finish: it usually means the sprint is too full or a risk hasn't been discussed.

Common sprint planning mistakes

• Planning to 100%. A sprint with no slack fails at the first surprise. Leave a buffer and keep stretch stories ready instead.
• Ignoring unfinished work. Stories carried over from the last sprint use this sprint's capacity. Re-estimate the remaining work and count it.
• Refining during planning. If most of the meeting is spent understanding stories, move that work into refinement.
• A goal that is just a list. "Do these eight tickets" gives the team nothing to decide with when plans change.
• Letting one voice set the estimates. When the lead says a number first, everyone else adjusts towards it. Vote privately and reveal together.

What a sprint planning tool should do

You don't need one big tool for sprint planning, but each step benefits from the right one:

• An ordered backlog with ready stories, usually in your issue tracker, such as Jira, Azure DevOps or Linear.
• Quick, fair estimation that the whole team can join from a link, with votes kept hidden until everyone has chosen.
• A running total of the estimates, to compare against your capacity as you add stories.
• A visible goal: on the board, in the team channel, wherever the team looks every day.

Storyvote covers the estimation part. Add the stories you are considering, vote on each one with hidden cards, and the Stories panel adds up the saved estimates as you go, so you can see when you have reached your capacity. It's free, needs no account, and lets you split a story into disciplines such as frontend, backend and QA, each with its own estimate.

Sprint planning FAQ

How long should sprint planning take?

The Scrum Guide caps it at eight hours for a one-month sprint and less for shorter sprints. In practice, about one hour per week of sprint is a good upper limit: two hours for a two-week sprint. If you regularly need more, invest more in backlog refinement.

Who should attend sprint planning?

The whole Scrum team: the product owner, every developer (including testers, designers and anyone else who does the work) and the Scrum Master. The team can invite others, such as a specialist, to give advice.

What is the difference between backlog refinement and sprint planning?

Refinement is ongoing preparation. It clarifies, splits and estimates upcoming stories. Sprint planning is the event at the start of a sprint, where the team sets a goal and commits to work that is already refined.

What happens if we can't finish everything?

Unfinished stories go back to the product backlog. The product owner reorders them, and the team can pick them up again in a later sprint. What matters most is the sprint goal: if the team meets it, the sprint did its job even if a stretch story waits.

← All articles