Sprint planning is the most consequential meeting in a Scrum team's week. When it goes well, the team leaves with a clear goal, a realistic backlog, and confidence they can ship. When it goes badly, the sprint starts with confusion, overcommitment, and resentment that festers for two weeks.
The Two Parts of Sprint Planning
The Scrum Guide divides sprint planning into two questions:
Part 1 — Why is this sprint valuable?
The Product Owner presents the sprint goal and the highest-priority backlog items. The team understands why these items matter before deciding how much to commit to.
Part 2 — How much can we do?
The development team forecasts how many backlog items they can complete, breaks them into tasks, and creates the sprint backlog. This is the team's commitment, not the PO's.
Before the Meeting: Backlog Refinement
Sprint planning only works if the backlog is ready. Items at the top of the backlog should be:
- Estimated — sized in story points or hours before the meeting, not during it
- Clear — acceptance criteria written, ambiguity resolved
- Independent — not blocked by other stories
- Small enough — completable within the sprint
Backlog refinement (formerly "grooming") should happen 1–2 times per sprint, 30–60 minutes each, to keep the top of the backlog ready. Sprint planning is not the time to discover that stories are too large, unclear, or blocked.
The Sprint Planning Agenda
For a 2-week sprint, the Scrum Guide recommends a maximum of 4 hours. Realistically, 2–3 hours is enough for a well-prepared team.
| Phase | Time | Purpose |
|---|---|---|
| Sprint goal | 10 min | PO presents; team aligns on what success looks like |
| Capacity check | 10 min | Account for PTO, meetings, on-call, other commitments |
| Story walkthrough | 60 min | PO walks top-priority stories; team asks questions |
| Estimation (if needed) | 30 min | Size any stories not yet estimated |
| Commitment | 20 min | Team selects items to fill capacity |
| Task breakdown | 30 min | Break selected stories into tasks |
| Wrap + confirm goal | 10 min | Read the sprint goal aloud; confirm everyone's aligned |
Capacity Planning Done Right
A common sprint planning mistake: planning to 100% capacity and wondering why the sprint always fails to deliver.
Account for:
- Meetings and ceremonies (~4–6 hrs/week for most engineers)
- PTO and holidays
- On-call rotation (typically 20–30% of one engineer's bandwidth)
- Unplanned work (bugs, urgent requests) — budget at least 15–20% of total capacity
A team of 5 engineers × 10 days × 8 hrs = 400 hrs. After overhead: 280–320 hrs is a realistic development budget. Plan to 80% of that.
Writing a Good Sprint Goal
A sprint goal should answer: What will users or the business be able to do after this sprint that they couldn't do before?
❌ Bad sprint goal: "Complete 8 story points of backlog items"
✅ Good sprint goal: "Users can sign up with Google OAuth and complete onboarding without contacting support"
The sprint goal guides decisions when unexpected work arrives. If a blocker threatens the goal, the team knows what to protect. If new work arrives, the team evaluates it against the goal.
Common Sprint Planning Mistakes
Skipping the sprint goal. A sprint without a goal is just a list of tasks. When something goes wrong, the team has no way to decide what to cut.
Estimating in the meeting. Estimation during planning is too slow and too influenced by group dynamics. Estimate in refinement, use planning only to confirm.
The PO commits for the team. "We need these 12 stories done this sprint" is not sprint planning — it's task assignment. The development team commits; the PO presents priorities.
No task breakdown. Stories that go into the sprint without being broken into tasks often stall mid-sprint because nobody knows who's doing what.
Originally published at projiq.app
Top comments (0)