Sprint Planning That Actually Works

Sprint planning is the ceremony most teams get wrong. It either runs too long — two hours of developers staring at a screen while the product owner reads stories aloud — or too short, producing a vague commitment that nobody believes in. The result is predictable: sprints that miss their goals, developers who feel overcommitted, and stakeholders who lose trust in the team's ability to deliver.

The fix is not a better tool or a smarter framework. It is a structured approach that separates pre-planning from planning, focuses on outcomes rather than task lists, and accounts for reality instead of pretending every sprint will go perfectly.

Pre-Planning: Backlog Refinement

Sprint planning should not be where stories are first discussed. If the team is seeing stories for the first time during planning, the session will inevitably become a requirements workshop — which is a different activity entirely.

Backlog refinement (sometimes called grooming) should happen continuously throughout the sprint, typically in one or two dedicated sessions. The purpose is to ensure that stories at the top of the backlog are ready for planning. "Ready" means:

• The user story is clearly written with a stated business value.
• Acceptance criteria are specific, testable, and agreed upon by the product owner and the team.
• Dependencies are identified and either resolved or explicitly planned for.
• The team has a shared understanding of the technical approach. Not a detailed design — just enough clarity that they can estimate with reasonable confidence.
• The story is sized appropriately. If a story feels larger than what one or two developers can complete in a sprint, it needs to be split.

A useful test: if the product owner describes a story and the developers immediately start asking "but what about...?" questions, the story is not ready. Those questions should be resolved in refinement, not in planning.

At Pepla, our teams allocate roughly 10% of sprint capacity to refinement. That investment pays for itself by making planning sessions focused and efficient.

The Planning Session Structure

An effective sprint planning session for a two-week sprint should take no more than two hours. For a one-week sprint, one hour is sufficient. If your planning consistently exceeds these timeframes, the problem is almost certainly insufficient refinement, not insufficient planning time.

The session has two distinct parts:

Part 1: The "What" (30-45 minutes)

The product owner presents the proposed sprint goal and the prioritised stories that support it. This is not a requirements review — the stories should already be understood from refinement. The product owner explains why these stories are the priority right now and what business outcome the sprint should produce.

The team asks clarifying questions about priority, not about requirements. "If we cannot finish all five stories, which three matter most?" "Is the integration story a prerequisite for the reporting story?" "Is there flexibility on the scope of story X if we discover it is larger than estimated?"

Part 2: The "How" (45-75 minutes)

The development team discusses the technical approach for each story. This is where developers identify tasks, discuss design decisions, flag risks, and refine their understanding of the effort involved. The product owner is present but steps back — this is the team's domain.

For each story, the team should be able to answer: Who will work on it? What is the technical approach? What are the risks? And roughly how long will it take? If the answer to any of these questions is "we have no idea," the story is not ready and should be sent back to refinement.

Capacity Planning

Many teams plan sprints as if every team member will be available for the entire sprint, working at 100% capacity on sprint stories. This is fiction, and planning based on fiction produces fictional commitments.

Honest capacity planning accounts for:

• Holidays and leave. Check the calendar before planning. A team of six with two members on leave for three days each has significantly less capacity than a full team.
• Ceremonies and meetings. Standups, retrospectives, refinement sessions, demos, and planning itself all consume capacity. For most teams, ceremonies account for 10-15% of available time.
• Support and maintenance. If the team supports production systems, allocate a realistic percentage for unplanned support work. If history shows that the team spends 20% of their time on support requests, plan for 20% — not 5%.
• Focus factor. Developers are not productive for 8 hours per day, 5 days per week. Context switching, code reviews, conversations with colleagues, and administrative tasks consume time. A focus factor of 60-70% for actual development work is realistic for most teams.

Multiply the number of available developer-days by the focus factor, subtract ceremony time and known support allocation, and you have your actual capacity. Plan to that number, not to the theoretical maximum.

Sprint Goals: Not Just Task Lists

A sprint goal is a concise statement of what the sprint will achieve for the business. "Complete stories 42, 43, 44, 45, and 46" is a task list, not a goal. "Enable customers to self-register and place their first order without manual intervention" is a goal.

The distinction matters for several reasons. A goal gives the team a shared understanding of purpose. When mid-sprint decisions arise — and they always do — the goal provides a framework for making them. If a developer discovers that story 44 is more complex than estimated, the team can ask: "Is story 44 essential to achieving the sprint goal?" If yes, they find ways to deliver it, perhaps by descoping lower-priority stories. If no, they can defer it without failing the sprint.

Good sprint goals share these characteristics:

• They describe an outcome, not a list of outputs.
• They are achievable within the sprint with the available capacity.
• They are meaningful to stakeholders, not just the development team.
• They provide clear criteria for determining whether the sprint was successful.

Not every sprint lends itself to a clean, single goal. Infrastructure sprints, technical debt sprints, and bug-fix sprints may have multiple objectives. That is fine — the goal can reflect that reality. But having a goal, even an imperfect one, is significantly better than having no goal at all.

Handling Unknowns

Every sprint contains uncertainty. A story that looks straightforward might involve a third-party API that behaves unexpectedly. A database migration might take twice as long as estimated. A requirement might turn out to be ambiguous when implementation begins.

The worst approach is to ignore uncertainty and plan as if everything will go according to estimate. The best approach is to acknowledge uncertainty explicitly and plan for it.

Practical techniques:

• Spike stories. When a story involves significant technical uncertainty, create a time-boxed spike to investigate before committing to the full implementation. A four-hour spike that reveals the true complexity of an integration is far cheaper than discovering that complexity mid-sprint.
• Buffer capacity. Do not plan to 100% of available capacity. Leave 10-15% as buffer for the unexpected. If nothing unexpected happens — which rarely occurs — the team can pull additional stories from the backlog.
• Risk flags. During planning, explicitly identify stories where confidence in the estimate is low. This allows the team to tackle high-risk stories early in the sprint, when there is still time to adapt if they prove more complex than expected.

Definition of Ready

The Definition of Ready (DoR) is a checklist that a story must satisfy before it can be pulled into a sprint. It is the team's agreement about what "ready for development" means. A typical Definition of Ready includes:

• The story has a clear description and acceptance criteria.
• The story has been estimated by the development team.
• Dependencies have been identified and are either resolved or have a resolution plan.
• The story is small enough to complete within a single sprint.
• UX designs are available (if applicable).
• The product owner has confirmed the story is still a priority.

The DoR is a quality gate, not a bureaucratic hurdle. Its purpose is to prevent half-baked stories from entering the sprint and consuming time that should be spent building. Enforce it consistently, and your sprint planning will be faster, your sprints will be more predictable, and your developers will be less frustrated.

Common Antipatterns

Recognise these patterns and eliminate them:

• The "planning poker with no discussion" antipattern. The team estimates stories by holding up cards without talking about why they chose those numbers. The value of planning poker is in the conversation, not the cards.
• The "product owner dictates the plan" antipattern. The product owner tells the team what to commit to rather than presenting priorities and letting the team determine what is achievable. This destroys ownership and produces unrealistic commitments.
• The "let's just fill the sprint" antipattern. Stories are added to the sprint until capacity is reached, without regard for coherence or sprint goals. This produces a sprint that delivers disconnected pieces of functionality with no clear business outcome.
• The "we'll figure it out during the sprint" antipattern. Stories enter planning with unclear requirements, and the team assumes they will resolve ambiguity during implementation. They will — but at a much higher cost than resolving it during refinement.
• The "same plan every sprint" antipattern. The team never adjusts its planning approach based on what happened in previous sprints. If the last three sprints missed their goals by 30%, the team needs to change how it plans, not just plan harder.

If your team struggles with sprint planning, Pepla can embed an experienced Scrum Master into your workflow to establish better practices -- without disrupting your existing team.

Sprint planning is a skill that improves with deliberate practice. After each sprint, ask the team: "Did our plan accurately reflect what happened? If not, what would we do differently?" Over time, this feedback loop produces increasingly accurate and effective planning.