Sprint Planning: A Step-by-Step Guide for Product TeamsSprint Planning: A Step-by-Step Guide for Product Teams

Sprint planning is the event that starts every Sprint in Scrum. In one timeboxed session, the whole team agrees why the Sprint matters (the Sprint Goal), which backlog items it can realistically finish, and how it will start the work. The output is a Sprint Backlog the team believes in, not a list of tickets someone hopes will get done.

It sounds simple, and the meeting itself usually is. What makes it work or fail is everything around it: whether the backlog is ready, whether anyone checked who is on leave, and whether the team treats its forecast as a plan to adapt or a promise to defend. This guide covers the official definition, the preparation that makes planning fast, a five-step agenda, a worked capacity example and the mistakes that quietly break most sprints.

What sprint planning is (and what the Scrum Guide actually says)

The 2020 Scrum Guide describes Sprint Planning as the event that initiates the Sprint by laying out the work to be performed. The entire Scrum Team — Product Owner, Scrum Master and Developers — collaborates on the plan, and the Product Owner makes sure attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The team can invite other people to give advice.

The Guide organizes the event around three topics:

1. 1.Why is this Sprint valuable? The Product Owner proposes how the product could increase its value, and the whole team collaborates to define a Sprint Goal. The Sprint Goal must be finalized before planning ends.
2. 2.What can be Done this Sprint? The Developers select items from the Product Backlog, refining them as needed. Their past performance, upcoming capacity and Definition of Done make the forecast more reliable.
3. 3.How will the chosen work get done? The Developers plan the work needed to create an Increment that meets the Definition of Done, often by breaking items into pieces of one day or less. How they do this is their call alone.

Together, the Sprint Goal, the selected items and the plan for delivering them make up the Sprint Backlog. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint and is usually shorter for shorter Sprints. Many teams scale it proportionally — roughly four hours or less for a two-week Sprint — but that is a common rule of thumb, not a rule in the Guide.

Two details are often misremembered. First, the Developers select the work and size it; the Product Owner explains priorities and trade-offs but does not assign a quota. Second, the Sprint Goal is the commitment, not every individual ticket. The Guide says scope may be clarified and renegotiated with the Product Owner as more is learned, as long as nothing endangers the Sprint Goal and quality does not decrease.

If your team runs a continuous-flow system instead of fixed Sprints, much of this guide still applies to replenishment meetings, but the cadence differs. Our comparison of Kanban and Scrum workflows explains when each fits.

Before the meeting: preparation that makes planning fast

Most painful planning sessions are really refinement sessions in disguise. The team spends two hours discovering requirements that should have been clarified a week earlier. Use this checklist in the days before planning.

Backlog readiness

• The top of the Product Backlog is ordered, and the Product Owner can explain why item 1 ranks above item 5.
• Likely candidates have a clear outcome, acceptance criteria and known dependencies. The Scrum Guide calls items that can be Done within one Sprint “ready”; many teams add their own lightweight readiness checklist on top.
• Items are small enough to finish inside the Sprint. Anything that would take most of the Sprint should be split first.
• Design, security, data or legal input that blocks the work has been requested, not discovered on the day.

Keeping the backlog in this state is a continuous job, not a pre-meeting scramble. Our guide to backlog management and prioritization covers refinement, readiness and scoring methods in depth.

Capacity facts

• Public holidays and planned leave for every team member during the Sprint dates.
• Support or on-call rotations, interviews, training and other recurring commitments.
• Known interruptions: a release freeze, a customer migration, a conference.
• The team’s recent delivery data — completed points or item counts for the last three to five Sprints.

A draft goal

The Product Owner should arrive with a proposed objective tied to the Product Goal, not just a ranked list. The team may change it, but starting with a draft keeps the first topic short and focused.

Step 1: Agree the Sprint Goal

The Scrum Guide describes the Sprint Goal as the single objective for the Sprint. It gives the team a reason to work together and a way to decide what to drop when reality changes. “Finish MOB-231, MOB-244 and MOB-248” is a list, not a goal. A good goal describes a change a user, customer or stakeholder would notice.

Test the goal with one question: if half the selected items turned out harder than expected, would the goal still tell the team which half to protect? If yes, it is doing its job.

Step 2: Calculate realistic capacity

Capacity is the time the team can actually spend on Sprint work after leave, holidays, support duty and meetings. Velocity — the amount of work completed in past Sprints — tells you what the team tends to finish at normal availability. Combining the two gives a forecast grounded in evidence instead of optimism.

Worked example: a two-week Sprint for five Developers

Over the last four Sprints the team completed an average of 30 points with about 42 focus days available. This Sprint they have roughly 34 focus days, so a sensible forecast is around 30 × 34 ÷ 42 ≈ 24 points. If the team picks 30 points anyway “because that’s our velocity”, it is planning for a Sprint that does not exist.

Three cautions keep velocity useful. Use it only to forecast your own team; points are not comparable across teams. Never set it as a target, because teams will inflate estimates to hit it. And treat the result as a range, not a number — leave space for the unexpected, especially if the team carries support work. If you track hours, a timesheet with planned-versus-actual data gives an even clearer picture of where capacity goes; see our guide to time tracking and resource planning.

Step 3: Select items and clarify them

With a goal and a capacity range agreed, the Developers pull items from the top of the backlog. For each candidate, spend a few minutes confirming:

• How it contributes to the Sprint Goal — or, if it does not, why it still belongs in this Sprint (an urgent defect, a contractual deadline).
• The acceptance criteria and what “Done” means, including testing, documentation and release steps required by the Definition of Done.
• Dependencies: API access, a design approval, another team’s change, a data migration or a vendor.
• Size and uncertainty. If the team cannot agree on a rough size within a couple of minutes, the item probably needs splitting or a time-boxed investigation (a spike) first.

Stop selecting when the forecast reaches the lower end of your capacity range, not the top. It is easier to pull an extra item mid-Sprint than to explain why a third of the plan slipped. Many teams also keep one or two “stretch” items visibly separate so nobody mistakes them for the commitment.

Do not forget quality work. If testing happens outside the Sprint, the Increment is not Done. Software teams should plan test cases and regression runs as part of the work, not as a later phase — our guide to test management in software projects shows how to keep QA inside the Sprint.

Step 4: Plan how the work starts

The third topic is the one teams most often skip. Selecting items is not a plan; knowing who starts what tomorrow morning is. The Developers break the first items into tasks of a day or less, identify the order dependencies force, and agree how they will swarm on the highest-risk work early.

You do not need to decompose every item on day one. A practical approach is to plan the first two or three days in detail and leave later items at story level, refining them as the Sprint unfolds. The Scrum Guide describes the Sprint Backlog as a plan by and for the Developers that is updated throughout the Sprint, so it is meant to change.

Step 5: Make the plan visible and confirm

Before closing the session, record the following in the same place the team updates its work every day:

• The Sprint Goal, written where everyone sees it on the board.
• The selected items, with owners only where ownership helps coordination.
• Dependencies and known risks, each with a person who will chase it.
• The Definition of Done that applies to every item.
• Any stretch items, labelled as such.

Then ask each Developer a direct question: do you believe we can meet this Sprint Goal? A hesitant answer is valuable information. It is far cheaper to adjust scope now than on day eight.

A sample agenda for a two-week Sprint

A mature team with a well-refined backlog often finishes in half this time. If you regularly need the full timebox, the issue is almost always refinement, not the meeting.

During the Sprint: keep the plan alive

The Daily Scrum, a 15-minute event for the Developers, exists to inspect progress toward the Sprint Goal and adapt the Sprint Backlog. It is not a status report to a manager. Useful questions are “what is blocking the goal?” and “what should we swarm on today?”, not a round of individual updates.

When new work arrives mid-Sprint — and it will — make the trade-off explicit. The Product Owner and Developers decide together whether it replaces something of similar size or waits for the next Sprint. Silently adding work is how teams end up with half-finished Sprints and no clear reason why. If the Sprint Goal becomes obsolete, the Guide allows the Sprint to be cancelled, and only the Product Owner has the authority to do so.

Closing the loop: Sprint Review and Retrospective

Sprint planning only improves if the team learns from what happened. At the Sprint Review (timeboxed to four hours for a one-month Sprint), the team shows what it accomplished to stakeholders and discusses what to do next, which often reshapes the backlog before the next planning session. At the Retrospective (timeboxed to three hours for a one-month Sprint), it looks at how the Sprint went for people, interactions, processes, tools and the Definition of Done.

For planning specifically, the most useful retrospective questions are: How close was our forecast to what we finished? What interruptions did we not plan for? Which items turned out bigger than expected, and why? Choose one or two changes and check them next Sprint. Tracking forecast accuracy and carry-over over time is a better health signal than raw velocity; our article on project management KPIs covers which delivery metrics are worth watching.

Common sprint-planning mistakes

Fix one or two of these at a time. Teams that try to overhaul every habit at once usually revert within a few Sprints.

Where QuikProjects fits

Sprint planning is easier when the backlog, the board, capacity and documentation are in one place. In QuikProjects you rank the backlog, run Scrum or Kanban on the board, list or spreadsheet-style view your team prefers, and map work on a timeline with dependencies and conflict warnings before dates collide. Capacity updates from schedules and holidays, and velocity is locked at Sprint close so the history you forecast from is not edited after the fact.

Unfinished work rolls into the next Sprint automatically, which saves admin — just re-rank it during planning rather than accepting it by default. Test cases and runs live in the same Space as the work, specs sit in a wiki next to it, and on Premium and Pro the AI Project Assistant summarizes Sprints and flags risks. Scrum, Kanban and backlog and Sprint planning are included on the free plan. For the bigger picture of how Sprints fit into delivery, see our guide to project management for software development teams and the complete guide to project management.

Frequently asked questions

How long should sprint planning take?

The Scrum Guide caps it at eight hours for a one-month Sprint and says it is usually shorter for shorter Sprints. For a two-week Sprint, two to four hours is typical, and well-refined teams often need less.

Who attends sprint planning?

The whole Scrum Team: Product Owner, Scrum Master and Developers. The team may invite others, such as a designer, architect or customer-support lead, to advise on specific items.

Is the Sprint Backlog a fixed commitment?

No. The Developers commit to the Sprint Goal. The selected items are a forecast, and scope can be clarified and renegotiated with the Product Owner as long as the Sprint Goal is not endangered and quality does not drop.

Do we need story points?

The Scrum Guide does not require them. Points, item counts and hours are all valid ways to size work. What matters is using one approach consistently so your own history can inform the next forecast.

Start your next Sprint with a plan the team believes in

Good sprint planning comes down to a clear goal, an honest capacity number and a first-day plan everyone can see. Keep the backlog refined, forecast from your own data and protect the goal when things change. If you want the backlog, Sprint board, timesheets, tests and docs in one workspace, try QuikProjects free — free for up to 10 users, no credit card needed.

Sources

• The 2020 Scrum Guide — Ken Schwaber and Jeff Sutherland