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. A recent LinkedIn thread on Stefan Wolpers’ sprint planning anti-patterns drew hundreds of practitioners trading the same war stories, so we pulled the eight that come up most and paired each with a concrete fix you can apply in Jira.
1. Planning without a sprint goal
The most common anti-pattern is treating planning as a ticket-selection exercise. Without a goal, every story carries equal weight and the team has no basis for trade-offs mid-sprint. Write one sentence that states the outcome before you pull a single item. We go deep on this in how to write a sprint goal.
2. Capacity theatre
Teams that plan to last sprint’s velocity while ignoring who is actually available this sprint are performing capacity theatre. Holidays, PTO, support rotations, and part-time allocations all shrink real capacity. Calculate available hours per person first, then commit against that number — not a historical average.
3. The backlog dump
Pulling whatever sits at the top of an unrefined backlog turns planning into a stuffing contest. If items aren’t refined, sized, and free of obvious blockers before the meeting, planning becomes refinement — and runs long. Keep refinement a separate, ongoing activity.
4. Ignoring hidden dependencies
Most sprints fail on dependencies, not effort. A story that needs another team’s API, a design sign-off, or a shared environment is not “ready” just because it’s estimated. Surface cross-team and cross-issue dependencies during planning so they become visible commitments, not mid-sprint surprises.
5. Over-commitment by optimism
Teams routinely plan to 100% of capacity and leave nothing for the inevitable interrupt, bug, or scope discovery. Planning to roughly 80% of capacity absorbs the unexpected and is the single biggest lever against chronic sprint rollover.
6. The silent product owner
When the PO drops a priority list and leaves, the team estimates in a vacuum. Planning needs the PO present to answer “why” and to renegotiate scope live as capacity reality lands.
7. Estimating in a vacuum
Solo estimates and “just put a number on it” skip the conversation where hidden complexity surfaces. 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, “finished” means something different to every developer, and carryover masquerades as completed work. Agree the bar before planning, not at review.
Designing the anti-patterns out in Jira
Several of these traps — 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. It nets out PTO, part-time allocations, and shared assignments so the team commits against hours it actually has, and it flags over-commitment before the sprint starts rather than at the retrospective. Pair that visibility with a written goal and a real definition of done, and most of these anti-patterns simply have nowhere to hide.
Anti-patterns are easier to avoid when planning follows a repeatable structure. For the full workflow, start with our complete sprint planning guide, and see the related common sprint planning mistakes for more fixes you can apply this week.
Leave a Reply
Your email is safe with us.