Sprint Planning: How the Scrum Event Works
Many teams experience Sprint Planning in one of two extreme ways: either as an endless meeting that drags on for three hours and still provides no clarity, or merely as a ticket-shuffling exercise in Jira that could just as easily have been handled via email. Neither of these approaches aligns with the true purpose of Sprint Planning.
Sprint Planning: Key Takeaways
- Definition: Sprint Planning is the first event of every Sprint. The entire Scrum Team collaboratively plans what value the Sprint should deliver, which Backlog Items will be selected for it, and how the work will be done.
- Three Questions: The Scrum Guide 2020 structures Sprint Planning around three questions: Why (Sprint Goal), What (selected Items), and How (plan for implementation).
- Sprint Planning Duration: Maximum eight hours for a four-week Sprint, four hours for a two-week Sprint, two hours for a one-week Sprint. Well-prepared teams often need significantly less time.
- Roles: Product Owner, Scrum Team (Developers), and Scrum Master participate. The PO provides direction, and the team decides what it can realistically deliver.
- The Sprint Goal decides: A Sprint without a clear Sprint Goal is just a list of tasks. The goal gives Sprints meaning and direction.
- Preparation counts: An unrefined Product Backlog makes every Sprint Planning meeting a nightmare. Refinement before planning is not an optional step.
What is Sprint Planning?
Sprint Planning, according to the Scrum Guide 2020, is the event that initiates a Sprint. It is not a status meeting, not a task assignment meeting, and not an extension of the last Sprint Retrospective discussion. It is the moment when the Scrum Team decides where it will go for the next one to four weeks and why.
The crucial difference from traditional project planning: The team pulls the work itself from the Product Backlog (pull principle). The Product Owner suggests direction and priorities, but the team decides what it can actually deliver in a Sprint. This self-commitment is not a minor detail; it is the foundation of reliability in agile software development.
What three questions does the Sprint Planning meeting answer?
A widespread representation from older Scrum versions states that Sprint Planning answered two questions: What and How. The Scrum Guide 2020 has evolved this. Today, three questions are at the core:
Why?
Why is this sprint valuable for the product and its stakeholders? The answer is the Sprint Goal. It is defined collaboratively and must be agreed upon before the Sprint Planning session ends.
What?
Which Product Backlog items will be worked on during this sprint? The team and Product Owner jointly select what is necessary and realistic to achieve the Sprint Goal.
How?
How will the team implement the selected items? Developers plan tasks, dependencies, and initial implementation steps. This part belongs to the team.
The "Why" question represents the substantive progress compared to the old two-part division. It ensures that the Sprint pursues a clear goal. A Sprint Goal is a statement that describes what value the Sprint creates for users or the product.
How long does a Sprint Planning last?
The Scrum Guide defines a timebox based on the sprint length:
- 1-week sprint: max. 2 h
- 2-week sprint: max. 4 h
- 4-week sprint: max. 8 h
These are upper limits, not mandatory durations. Teams with a well-maintained backlog, clear Sprint Goal, and established collaboration often complete the meeting in half the time. Teams that regularly exceed the timebox usually have a backlog problem: items are too large, too unclear, or insufficiently prepared. The actual Sprint Planning Meeting then suffers from work that should have been handled during refinement.
The 60-70% Capacity Rule: A 2-week sprint does not equate to 10 × 8 hours of pure development time. Daily Scrums, refinement sessions, unplanned support requests, and meetings realistically consume 30 to 40 percent of the nominal capacity. Ignoring this during Sprint Planning leads to systematic over-planning.
Which roles are involved in Sprint Planning?
All members of the Scrum Team participate in Scrum Sprint Planning:
- The Product Owner brings a prioritized, understandable backlog and explains the proposed Sprint Goal for the current sprint and its rationale. They provide business context, answer questions, and serve as the point of contact for scope decisions. However, they do not impose tickets on the team.
- The Developers select which items they believe are achievable, estimate the effort, and plan the concrete implementation in the second part of the meeting. They are responsible for providing a realistic statement about what the sprint will deliver.
- The Scrum Master ensures that the meeting takes place, stays within the timebox, and that the team can work productively. They act as a facilitator and coach, not a note-taker.
Stakeholders can be invited if they can answer specific domain-related questions for the team. However, they do not decide what the team commits to for the sprint.
How does a Sprint Planning Meeting proceed?
Jointly formulate the Sprint Goal
The PO proposes why the sprint is valuable. The team discusses and jointly formulates a Sprint Goal that everyone supports. This statement must be precise and meaningful; it is not a wish list.
Check Capacity
The team realistically assesses the available capacity: vacations, holidays, known meetings, and ongoing support commitments. Realistically planned capacity is often 60 to 70 percent of the nominal time.
Select Backlog Items
The team pulls items that align with the Sprint Goal and can realistically be completed within the available capacity. This is based on velocity from previous sprints and current capacity.
Develop Implementation Plan (The "How")
The Developers specifically plan how they will approach the selected items. Items are often broken down into tasks. The PO is usually not actively involved but remains available for questions.
Finalize the Sprint Backlog and Start the Sprint
The result of Sprint Planning is a Sprint Backlog with the Sprint Goal, the selected items, and the implementation plan. The Sprint begins immediately afterward.
What makes a good Sprint Goal?
The Sprint Goal is the most powerful tool in Sprint Planning, and at the same time, it's what is most often done poorly in practice. A Sprint Goal is not a ticket title and not a list of features. It describes in one sentence the value the sprint brings to users or the product.
The difference in practice:
| Bad Sprint Goal | Good Sprint Goal |
|---|---|
| "We complete PROJ-112, PROJ-118 and PROJ-124 and fix the bug from the last retrospective notes." | "Users can change their billing address in their customer account themselves, without having to contact support." |
A poor Sprint Goal is a ticket list. It gives the sprint no direction, no prioritization, and no criterion for whether the sprint was successful. A good Sprint Goal describes a specific user problem that is being solved. If the scope of items changes during the sprint, there is still a clear basis for decision-making.
A helpful approach to formulation: Write Sprint Goals in the present tense, from the user's perspective. "Users can X" instead of "We build Y". This makes the value tangible.
{{fs-banner-cta}}
What are the most common mistakes in agile Sprint Planning?
Most problems in Sprint Planning don't arise during the meeting itself, but beforehand or due to incorrect expectations of the process.
| Mistake | Why It Happens | How to Fix It |
|---|---|---|
| No Sprint Goal | The team focuses on individual tickets instead of the overall value of the sprint. | Always formulate the Sprint Goal first, before items are selected. |
| Unprepared Backlog | No refinement before planning; items are unclear, too large, or not prioritized. | Introduce regular backlog refinement in the middle of the running sprint. |
| Overestimated Capacity | Nominal hours are treated as available development time. | Use 60–70% of nominal capacity as the planning basis, and deduct meetings and support. |
| PO Chooses the Work | The pull principle is replaced by push, and the team does not feel responsible. | The team selects the work itself; the PO provides context and prioritization, not commitments. |
| Planning Becomes Estimation | Story point discussions consume the timebox without producing more clarity. | Move estimation into refinement; re-estimate during planning only where there is genuine uncertainty. |
| No Definition of Ready | Items enter planning that are not yet actionable: no acceptance criteria, open dependencies. | Establish a Definition of Ready as the entry ticket for Sprint Planning. |
What needs to be prepared before Sprint Planning?
The biggest lever for effective Sprint Planning lies outside the meeting itself. A Sprint Planning meeting that exceeds its timebox almost always indicates a preparation issue.
Checklist: Sprint Planning Preparation
- Product Backlog maintained: Priorities are current, items prioritized by value and dependencies
- Top items refined: Items considered for the sprint have clear acceptance criteria and are broken down to sprint size
- Velocity known: The team knows how much it has accomplished in recent sprints
- Capacity accounted for: Vacations, holidays, and known absences are known for the upcoming sprint
- Sprint Goal proposal available: The PO has prepared a direction, even if the final goal is formulated collaboratively
- Last Retrospective considered: Insights from the last sprint are incorporated into the process or backlog
Iterative Software Development with Axisbits
Axisbits develops software projects iteratively, with structured sprints, clear communication, and a client-side Product Owner who always has insight into the development status. We bring Scrum experience from over 100 projects and adapt processes to the size and maturity of the undertaking.
- Sprint-based Development: Two-week sprints with clear Sprint Goals, prioritized backlogs, and regular reviews in which you, as the client, are actively involved.
- Transparent Progress: After each sprint, you see working software, not just a status report.
- Flexible Scope: New requirements can be introduced between sprints without replanning the entire project.
- Introduction to Agile Processes: If your team is new to Scrum, we guide the establishment of structured planning and review processes.
{{fs-btn-cta}}
Agile Software Development with Axisbits
We develop your product iteratively, with clear sprints, structured processes and direct communication. In the Project Review we clarify how best to approach your project.
Wir schaffen leistungsstarke Plattformen und Websites für Startups, Scale-Ups und KMUs, von Konzept bis Go-Live.
We develop your product iteratively, with structured sprints and a clear project focus.
Sprint Planning: Frequently Asked Questions
Sprint Planning is a formal Scrum event at the beginning of a Sprint, where the team decides what it will deliver in the upcoming Sprint. Backlog Refinement is an ongoing activity (not a formal event) where items for upcoming Sprints are prepared, detailed, and estimated. Refinement is the preparatory work, Sprint Planning is the decision. Teams that do not conduct regular Refinement almost always find their Sprint Planning to be lengthy and unproductive.
The PO should be fully present for the first part of the meeting: to formulate the Sprint Goal, present the items, and answer questions. In the second part, when the team concretely plans how the items will be implemented, the PO is often less actively involved. However, they should remain available in case clarification is needed. They must not be completely absent: Sprint Planning without a PO is like a briefing without the client.
This is significantly better than selecting too many items. A team that fully completes its sprint scope can, in consultation with the PO, pull additional items from the backlog. A team that systematically over-plans regularly delivers unfinished work and accumulates technical debt. It's better to make a conservative forecast and then pull in more, than to consistently promise more than can be delivered.
Unplanned work is normal. The Sprint Goal helps prioritize: If the new task aligns with the Sprint Goal, the team can take it on and negotiate other scope accordingly. If it doesn't, it goes into the backlog for the next sprint. If unplanned work regularly derails the sprint, it's a signal for the next Sprint Planning: Plan for capacity buffers and explicitly account for support effort.
No, Story Points are not part of the Scrum Guide. They are a common tool that teams use to estimate relative complexity and measure velocity. Alternatively, T-shirt sizes (S/M/L), the number of days, or simply the team's assessment of whether an item fits into the sprint can work. What matters is a shared understanding of what can realistically be completed within the available capacity.
More articles
According to the swissICT Digital Excellence Report, only 35 percent of Swiss companies are on track with their digital alignment. For 26 percent, there is significant need for action (Source: swissICT). Companies invest in tools, cloud services, and AI pilot projects without a plan that holds it all together. The result: fragmented system landscapes, duplicated work, and budgets that don't flow where they have the most impact. The right IT strategy is the answer to this.
Artificial intelligence is now an established tool in software development, integrated directly into the programming environment. Developers spend less time writing boilerplate code and can instead focus on how the different parts of an application logically interact.
According to the PwC report Digital Product Development 2025, so-called 'Digital Champions' – companies with a high level of digital maturity – are already expecting and achieving an efficiency increase of 31% and a 20% reduction in operating costs.