Sprint Planning Discipline

Overview

Sprint planning converts a prioritised backlog into a committed, understood sprint plan. A well-run planning session ends with a sprint goal, a set of stories the team is genuinely confident it can complete, and a shared understanding of the work. A poorly run one ends with a list of stories that felt achievable under time pressure but collapse within the first three days of the sprint.

For keeping the backlog in a state where planning can succeed, see Backlog Refinement Practices. For tracking delivery after planning, see Velocity Tracking.

Why It Matters

Overcommitment is the most common failure mode in sprint planning. Teams that commit to more work than they can complete consistently underdeliver, produce inaccurate velocity data, and carry unfinished work into subsequent sprints — compounding the problem.

A sprint without a goal is a list of tasks. A sprint goal gives the team a single sentence that describes what they are trying to achieve. It provides a decision-making framework mid-sprint when priorities conflict and makes sprint review conversations coherent for stakeholders.

Under-prepared stories destroy planning session time. When stories arrive at planning without acceptance criteria, without designs, or with unresolved open questions, the planning session becomes a refinement session. The team estimates poorly and commits to work they do not understand.

Capacity planning is not optional. A team of five developers does not have five full sprints of development capacity. Meetings, on-call rotations, planned leave, and onboarding reduce available capacity significantly. Ignoring this produces overcommitment in every sprint.

Shared understanding prevents mid-sprint surprises. The point of walking through stories in planning is not to fill time — it is to ensure every developer could describe what they are building and why. Surprises that surface during development usually trace back to stories nobody fully understood at planning.

Standards & Best Practices

Setting the sprint goal

The sprint goal is a single sentence written before the team selects stories. It answers: "If we complete this sprint successfully, what is true that wasn't true before?"

Good sprint goals:

• "Customers can check out without entering payment details on repeat purchases"
• "The admin dashboard loads in under 2 seconds for all user tiers"
• "The mobile app works fully offline for the core product creation flow"

Bad sprint goals:

• "Continue working on the checkout improvements" (describes activity, not outcome)
• "Stories from the backlog" (not a goal at all)
• "Do everything in the backlog" (not achievable)

Stories selected for the sprint should contribute to the sprint goal. Stories that do not contribute are either lower priority or belong in a different sprint.

Capacity planning

Calculate available capacity before selecting stories:

1. Count available developer-days: team size × sprint days
2. Subtract non-development time: planned leave, company events, on-call, regular meetings
3. Apply a focus factor: developers are not productive 100% of their time. A focus factor of 70–80% is typical.
4. Convert to story points: use the team's historical average points-per-developer-day

Example for a 5-person team on a 10-day sprint:

• Gross capacity: 50 developer-days
• Minus: 5 days (leave/events) = 45 days
• Minus: 20% overhead = 36 effective days
• At 3 points/day average: 108 points available

If the team's recent velocity is 80 points per sprint, plan for 80 — not 108. Capacity ceiling and historical velocity should agree; when they don't, investigate why.

Story walkthrough in planning

For each story the team considers:

1. Product manager reads the story and acceptance criteria aloud
2. Developer who is likely to own the story asks clarifying questions
3. Team agrees the story meets Definition of Ready
4. Team confirms the estimate (or re-estimates if new information surfaced)
5. Dependencies are confirmed unblocked

Stories that generate more than 5 minutes of discussion are typically not ready. Move them out rather than planning around ambiguity.

Commitment vs selection

There is a meaningful difference between:

• Selected: "We think we might be able to do this"
• Committed: "We will deliver this by the end of the sprint"

Teams should commit only to stories they are confident they can complete. A partial list with high confidence is better than a full list with low confidence. "Stretch goals" — stories added after the core commitment is full — are acceptable as long as they are explicitly labelled and not counted in the sprint commitment.

How to Implement

Sprint planning meeting structure

Before the meeting (product manager):

• Confirm backlog priority with stakeholders
• Ensure top stories meet Definition of Ready
• Draft the sprint goal
• Prepare capacity calculation

Part 1 — Sprint goal (15 min):

• Product manager presents the proposed sprint goal
• Team discusses and agrees or refines
• Sprint goal is written down and visible throughout planning

Part 2 — Story selection (45–90 min):

• Walk through each story in priority order
• Confirm story is understood and ready
• Confirm estimate
• Stop when capacity is reached

Part 3 — Dependency and risk check (15 min):

• Are there any cross-team dependencies that could block stories?
• Are there any stories with elevated risk (new technology, unclear acceptance criteria)?
• Are there any stories that should be re-ordered based on dependencies?

Wrap-up:

• Confirm sprint goal still applies to the selected stories
• Record the sprint plan (committed stories + stretch goals if any)

Planning output checklist

Before closing the planning session:

• Sprint goal is written and agreed
• All committed stories meet Definition of Ready
• Capacity calculation is documented
• Total committed points are within capacity
• Stretch goals are labelled separately
• Dependencies are mapped
• Sprint board is updated

Tools & Templates

Capacity calculator template

## Sprint [N] — Capacity Calculation

**Sprint dates:** [Start] → [End]
**Team size:** [N] developers

| Developer | Available days | Unavailable (leave/events) | Effective days |
| --------- | -------------- | -------------------------- | -------------- |
| [Name]    | [total]        | [days out]                 | [effective]    |
| [Name]    | [total]        | [days out]                 | [effective]    |
| **Total** |                |                            | **[sum]**      |

**Focus factor:** [70–80%]
**Effective development days:** [sum × focus factor]
**Historical velocity (last 3 sprints avg):** [X] points
**Planned sprint capacity:** [min of historical avg and calculated capacity] points

Sprint planning agenda

## Sprint [N] Planning — [Date]

**Duration:** [90–120 min]

**Agenda:**

1. Sprint goal proposal and agreement (15 min)
2. Story walkthrough and selection (60–90 min)
3. Dependency and risk check (15 min)
4. Confirm sprint plan (10 min)

**Sprint goal:** [Fill in during session]
**Committed points:** [Fill in during session]
**Stretch goals:** [Fill in during session]

Common Pitfalls

Planning to theoretical capacity, not historical velocity. A team that averaged 60 points over the last four sprints should plan for 60 points — not 80, regardless of what the capacity calculation says. Historical velocity accounts for all the real-world factors the calculation misses.

Walking into planning with unprepared stories. If more than 20% of the stories selected for a sprint required significant discussion in planning, refinement has failed. Planning is for commitment and confirmation, not for discovery.

No sprint goal. Sprints without goals produce teams that treat the sprint as a list of disconnected tasks. When priorities shift mid-sprint, there is no framework for making trade-offs. Sprint goals make mid-sprint decisions faster and sprint reviews more meaningful.

Committing to everything and labelling it all "committed." Teams under pressure to show high output commit to more than they can deliver and then carry work over. Two sprints of 70% delivery is worse for the team and stakeholders than consistently delivering 90% of a modest commitment.

Estimating during planning. Stories that have not been estimated before planning add unpredictability to the session. Time spent estimating in planning is time not spent understanding the work. Estimation belongs in refinement.

Not confirming dependencies. A story that depends on an API another team hasn't deployed, a design that isn't finished, or a third-party credential that isn't set up will block a developer mid-sprint. Five minutes at the end of planning to check dependencies prevents days of blocked work.