Sprint Planning Anti-Patterns: 8 Traps That Quietly Wreck Delivery
📄 Canonical version: this article was first published on divim.io — Sprint Planning Anti-Patterns: 8 Traps That Quietly Wreck Delivery. This is an internal mirror.
Ask an experienced Scrum Master what kills a sprint and they rarely say "hard work." They point to sprint planning anti-patterns — the quiet, repeatable habits that make a plan look complete on the board while it is already doomed. Drawn from an active LinkedIn discussion on sprint planning anti-patterns, here are the eight that come up most, each with a concrete fix you can apply in Jira.
1. Planning without a sprint goal
Without a goal, every story carries equal weight and the team has no basis for trade-offs mid-sprint. Write one sentence stating the outcome before you pull a single item.
2. Capacity theatre
Planning to last sprint's velocity while ignoring who is actually available is capacity theatre. Calculate available hours per person first, then commit against that number.
3. The backlog dump
Pulling whatever sits at the top of an unrefined backlog turns planning into a stuffing contest. Keep refinement a separate, ongoing activity.
4. Ignoring hidden dependencies
Most sprints fail on dependencies, not effort. Surface cross-team and cross-issue dependencies during planning so they become visible commitments.
5. Over-commitment by optimism
Planning to 100% of capacity leaves nothing for the inevitable interrupt. Planning to ~80% absorbs the unexpected and is the biggest lever against rollover.
6. The silent product owner
Planning needs the PO present to answer "why" and renegotiate scope live as capacity reality lands.
7. Estimating in a vacuum
Collaborative estimation isn't about precision — it's about the disagreement that exposes risk before you commit.
8. No definition of done
Without a shared definition of done, carryover masquerades as completed work. Agree the bar before planning.
Designing the anti-patterns out in Jira
Capacity theatre, over-commitment, and ignoring availability share one root cause: planning against a guess instead of real, per-person capacity. Sprint Planning, Capacity & Resource Planning for Jira makes available capacity explicit during planning — netting out PTO, part-time allocations, and shared assignments, and flagging over-commitment before the sprint starts.