Sprint Planning: Step-by-Step Guide

Most sprint disasters do not happen during the sprint. They happen in the 90 minutes before it, when a team sits down with an unprepared backlog, no clear goal, and a silent room full of people who are not sure what they are committing to. Sprint planning is the event that turns a vague pile of backlog items into a focused two-week commitment, and getting it wrong derails everything that follows. This guide walks you through sprint planning step by step — the preparation, the three questions every great planning session answers, the estimation and capacity math, and the outputs you should never leave the room without.

Quick Answer: What is sprint planning?

Sprint planning is the first event of a sprint, where the entire Scrum Team collaboratively decides what the sprint will accomplish and how. It answers three questions: why this sprint is valuable (the sprint goal), what can be done this sprint (selected Product Backlog items), and how the chosen work will get done (the delivery plan). The result is the Sprint Backlog, and it is time-boxed to a maximum of eight hours for a one-month sprint.

The nuance: sprint planning is a negotiation, not a sign-off. The Product Owner proposes value, the Developers commit based on real capacity, and the plan stays “just enough” — detailed enough to start, not so detailed that it becomes a straightjacket.

Why does sprint planning matter?

Sprint planning is where the team converts strategy into a commitment. Without it, teams either start a sprint with a fuzzy idea of what “success” means, or they spend the sprint fighting over priorities that should have been settled before day one.

Good planning produces three concrete things: a sprint goal everyone can repeat from memory, a backlog that fits the team’s actual capacity, and a shared understanding of the plan. Bad planning produces a sprint that drifts, a review with nothing valuable to show, and a retrospective full of “we should have planned better” — which is true, but useless if no one changes the ritual.

Planning also forces the conversation about trade-offs. When a Product Owner asks for 40 story points and the Developers know they delivered 26 last sprint, the gap is surfaced before work starts instead of at the deadline. That is the entire point: make the hard conversation happen in a meeting room, not in a panic on the last day.

Who should attend sprint planning?

The entire Scrum Team attends: the Product Owner, the Scrum Master, and the Developers. The Product Owner ensures the room is prepared to discuss the most important backlog items and how they map to the Product Goal. The Developers bring the knowledge of what they can realistically deliver and how they will do it. The Scrum Master facilitates, keeps the event within its time box, and makes sure the decisions are captured.

Other people can be invited to provide advice, but they are advisors, not decision-makers. A stakeholder who attends and starts demanding extra features mid-planning is a sign the team has not protected the event. If a key person cannot attend, the team should consider rescheduling rather than planning around an empty chair — a sprint plan built without the Product Owner or the Developers is fiction.

What are the inputs to sprint planning?

Four things need to be ready before the meeting starts, or the session will burn its time box on questions it should not have to answer.

• A refined Product Backlog. Items the team might pull into the sprint should already be broken down, sized, and clear enough to discuss. Backlog refinement is an ongoing activity, not a sprint-planning sidebar. As a rule of thumb, for a two-week sprint, teams hold a refinement session mid-sprint to prepare the next one.
• The Product Goal and the Product Owner’s direction. The PO comes with a view of what would increase the product’s value this sprint. This is the “why” material.
• Team capacity. How many focused person-hours or story points the team actually has, accounting for leave, ceremonies, support work, and other meetings. Naive capacity ignores reality; effective teams bake it in.
• Historical velocity and past data. What the team actually delivered in recent sprints, not what it hopes to deliver. Velocity, the Definition of Done, and the previous review’s feedback all inform a realistic forecast.

What are the three topics of sprint planning?

The Scrum Guide defines sprint planning around three topics. Covering them in order keeps the session structured and prevents the classic trap of jumping into task-level detail before the goal exists.

Topic One: Why is this sprint valuable?

The Product Owner proposes how the product could increase its value in the sprint, and the team collaborates to define a Sprint Goal — a single objective that communicates why the sprint is valuable to stakeholders. The goal must be finalized before the end of planning. A good goal is outcome-focused (“Let users recover their account without contacting support”) rather than task-focused (“Do 12 support tickets”). It is the anchor the team returns to every day, and the thing that gets renegotiated (never silently dropped) if scope shifts.

Topic Two: What can be done this sprint?

Through discussion with the Product Owner, the Developers select Product Backlog items for the sprint, and the team may refine them during the session to increase understanding. Selecting the right amount is a forecast based on past performance, upcoming capacity, and the Definition of Done. The honest question is not “what can we dream of?” but “what have we delivered before, adjusted for what we know now?”

Topic Three: How will the chosen work get done?

For each selected item, the Developers plan the work needed to create an increment that meets the Definition of Done — usually by decomposing items into tasks of one day or less. This is solely the Developers’ call; no one else tells them how to turn backlog items into value. Task-level decomposition also makes the Daily Scrum useful, because the team can see what moved and what is stuck.

How long should sprint planning take?

The Scrum Guide sets the maximum at eight hours for a one-month sprint, with shorter sprints usually getting proportionally less. A widely used practical guideline is no more than two hours for each week of the sprint: a two-week sprint gets up to four hours, a one-week sprint up to two. The time box is a maximum, not a target — if the team is done in 90 minutes, the event is over.

Length is a symptom, not the goal. A team that plans a two-week sprint in three hours and leaves with a clear goal, a realistic backlog, and a plan is doing it right. A team that spends five hours because the backlog was a mess and the room argued about estimation is paying for preparation debt, not doing better planning.

Sprint planning step by step: the full agenda

Follow this order and you will cover the three topics without the room drifting.

Step 1: Set the context (15-30 minutes). The Product Owner shares the Product Goal, recent stakeholder feedback, and the state of the previous increment. The team reviews what actually shipped last sprint.

Step 2: Propose and shape the sprint goal (30-45 minutes). The PO proposes a goal; the team discusses whether it is achievable and valuable. Keep iterating until there is one crisp sentence everyone agrees on. This step ends only when the goal is written down and visible.

Step 3: Select the backlog items (45-90 minutes). Walk the refined backlog top-down. For each candidate item, check: does it serve the goal? Is it ready (clear, sized, dependency-free)? Do we have the skills and capacity? Pull items in until the forecast matches capacity, then stop.

Step 4: Forecast with capacity and velocity (20-30 minutes). Compare the total size of selected items against known velocity and real capacity. If the forecast exceeds capacity, negotiate with the PO — swap items, re-scope, or defer. Never accept an overloaded sprint to please anyone.

Step 5: Decompose into a plan (45-90 minutes). The Developers break each selected item into tasks of one day or less and assign owners. Capture dependencies, risks, and anything needed from outside the team. Leave the room with every item having a realistic path to “Done.”

Step 6: Finalize the Sprint Backlog (10-15 minutes). Confirm the sprint goal is fixed, the item list is locked, and the plan is visible on the board. Assign owners, due dates, and make sure the board reflects reality before anyone leaves.

How do you estimate and set capacity honestly?

Estimation is a forecast, not a promise. The two most common approaches are story points (relative sizing) and hours. Story points measure effort relative to other work and, combined with historical velocity, produce a capacity-based forecast. Hours feel concrete but are easily gamed by padding. T-shirt sizing (S/M/L/XL) is a fast middle ground for teams that want less ceremony.

The key discipline is separating estimation from evaluation. If estimates are used to punish people after the sprint, the team will inflate them forever. Estimation works when the team knows the numbers are used for planning, not performance review. A simple test: if your velocity chart has been climbing steadily every sprint, ask whether the work is really getting easier or the estimates are getting friendlier.

Capacity is separate from estimation. A team of five developers at 100% capacity does not have five × 40 hours of sprint work, because sprints contain planning, daily scrums, review, retrospective, and real-world interruptions. Effective teams discount capacity by 20-30% for meetings, support, and context switching, then re-check against what they delivered last sprint.

Two worked examples of sprint planning

Example 1: A two-week sprint with a healthy plan. A 4-person team, two-week sprints, historical velocity of 22 points. Capacity this sprint drops to 18 because one developer is on leave. At planning, the PO proposes the goal “Speed up checkout.” The team walks the refined backlog, selects 20 points of items, then the forecast conversation brings it down to 18 — one medium story is deferred. Tasks are broken out in 45 minutes. The whole session takes 3 hours 20 minutes. Sprint result: 18 points delivered, goal met, next planning session starts with a clean board and a calm team.

Example 2: A one-month sprint where planning was skipped. A team that “hates meetings” skips refinement and runs a 90-minute planning session for a one-month sprint. The PO lists 60 points of items, nobody checks capacity, and the board is filled with large, unbroken epics. Two weeks in, half the tasks are still “in progress,” the burndown is flat, and the team discovers a dependency on another department that no one had flagged. At review, they demo almost nothing usable. The planning was not too long; it was too late — the decisions that should have happened in the session happened painfully during the sprint.

Example 3: The overloaded sprint that should have been refused. A Product Owner pressures the team to take 34 points because “the customer is waiting.” Last sprint the team delivered 24. The Scrum Master facilitates a capacity conversation: 34 points × the team’s real availability means overtime or half-done work. The team negotiates: 24 points now, the remaining work re-scoped and scheduled for next sprint, with a clear explanation to the customer. The customer gets a realistic date and the team protects quality. Saying no in planning is cheaper than explaining a missed deadline later.

Common Mistakes in Sprint Planning

Planning without a sprint goal. Without a goal, “planning” is just task picking, and the team has no anchor to renegotiate against mid-sprint.

Skipping backlog refinement. Planning a sprint against an unrefined backlog is like shopping without a list — the meeting becomes the refinement session, and it runs over.

Overcommitting to please the Product Owner. An overloaded sprint produces half-finished increments and an eroded Definition of Done. The Developers own the forecast; use the data.

Letting the PO or stakeholders dictate the how. The Developers own the plan for delivering work. When outsiders decide how work is done, the team stops self-managing and the plan gets detached from reality.

Confusing the time box with a minimum. Planning is done when the plan is good, not when the clock runs out. Stretching a finished session into a fourth hour adds no value.

Leaving without written decisions. Every scope negotiation, dependency, and risk should be captured in the project tool before people leave, or the room’s memory becomes the source of truth — and memories differ.

Know This Before You Choose

Before you lock in your planning ritual, answer these questions:

• Is your Product Backlog refined enough that planning can focus on selection rather than clarification?
• Does your team actually know its historical velocity, or are you estimating on hope?
• Have you accounted for real capacity — leave, ceremonies, support work, and meetings?
• Who owns the “how” in your room: the Developers, or everyone’s opinion?
• Does your planning session end with a visible, written Sprint Backlog, or with verbal agreements?
• Can your Product Owner say “no” to a stakeholder request that endangers the sprint goal?
• Is your planning time box proportional to your sprint length, or is it whatever fits the calendar?

Which tools support sprint planning well?

The right tool makes the plan visible and the data honest; the wrong one hides both behind configuration. Here is how common options compare.

Whatever you choose, the sprint goal and the board must be visible to the whole team at a glance. The plan lives in the tool, not in the planning meeting’s memory.

Where does sprint planning fit in a project management platform?

Sprint planning is only as good as the data it reads and the plan it produces. If capacity lives in one tool, the backlog in another, and the goal on a sticky note, the planning session becomes a reconciliation exercise. A platform that holds the backlog, the sprint goal, the task hierarchy, workload, and reports in one place makes the numbers real: capacity is derived from actual assigned work, velocity comes from completed tasks, and the Sprint Backlog produced in planning is the board the team works from all sprint. Doitify is built around that idea, with sprints and backlogs, multi-level tasks and sub-tasks, workload management, and work reports together so planning decisions are based on data, not memory. To be transparent: Doitify is our product, which is why we know its capabilities from the inside.

Still, start with the ritual. A whiteboard, a clear goal, and honest capacity beat a perfect Jira configuration every time. Get the conversation right first; let the tool support it second.

Conclusion

Sprint planning is a short meeting that carries an outsized share of the sprint’s success. Do it well and the team leaves with a goal it believes in, a backlog that fits its capacity, and a plan it can start tomorrow morning. Do it badly and the sprint pays the price in drift, missed dates, and retrospective regret. Prepare the backlog, answer the three questions — why, what, how — in order, plan to the real numbers, and write everything down. The sprint goal is your anchor, the Developers own the how, and the time box keeps everyone honest. Nail planning, and the rest of the sprint becomes execution instead of improvisation.