Why sprint planning keeps failing

In the room, planning runs long. Scope is still fuzzy when people leave. Half the tickets are “TBD.” Someone is still discovering the work during the meeting that was supposed to commit it.

During the sprint, the board stops matching the commitment. Unplanned work shows up. Carryover looks like the plan. People say they “knew this would happen.”

Split meeting symptoms (time, energy, leftover ambiguity) from sprint symptoms (commitment vs reality). If only the meeting hurts, facilitation may be enough. If the meeting is fine and the sprint still slips, the plan was fiction. Most teams have both, which is why swapping the agenda does not help.

The meeting is a bad place to discover work. Typical clusters:

Intake is late or vague. Items arrive at planning as titles. Acceptance is invented live. Estimates then measure ignorance, not effort.

Commitment ignores known interrupts. Support load, reviews, and “quick asks” are real. The plan pretends they are not. Mid-sprint work is then treated as a surprise.

WIP in discovery is unbounded. Too many half-ready items compete for the same planning slot. The team debates instead of choosing.

The commitment rule is social, not operational. Saying no to extra scope is harder than adding it. The room optimizes for harmony, then the board pays.

Facilitation is actually weak. Rare as the *only* cause, but real: no timebox, no parking lot, no “what would make this ready.” If 5 Whys keep landing on “we ran over because we talked a lot,” fix the room — then check whether the sprint still slips.

A missing icebreaker, a prettier board, or “we need more Agile training” can sit next to a working plan. They do not explain a plan that cannot survive the week.

Ask why the last sprint's plan broke, then why that cause was allowed, until you reach a process you can change this week. Stop at a cause the team owns. “Leadership is chaotic” is not a next action. “We committed to items with no owner for interrupts” is.

Work one failed sprint, not the mythology of the last quarter. Write the answers down in the same session.

Diagnostic prompts (stay on the last sprint):

1. What in the plan was false by Wednesday?
2. Was that work unknown on Monday, or known and excluded?
3. If it was unknown, where should it have been visible before planning?
4. If it was known, what rule let you commit anyway?
5. What would we refuse to commit next time if this answer is true?

Stop when two people can name the same cause in one sentence and point at a behavior (how items enter, how interrupts are budgeted, how “ready” is decided). If you are still on “communication” or “culture” after five whys, you went too abstract. Come back one level.

Diagnosis ends with a cause. Redesigning the whole ritual belongs in a later, smaller move.

Read the cause against where the pain showed up.

If every why ends in “we didn't know the work,” the planning meeting cannot save you. Ready work has to exist before the room. Actions sit in intake: a smaller ready queue, a cutoff, a rule that unready items are not estimated.

If it ends in “we knew and still overcommitted,” the fix is the commitment rule, not the agenda. Budget interrupts. Cap stretch items. Make “no” cheaper than a heroic yes.

If it ends in “we talked past the timebox,” facilitation may be the first PDCA. Timebox topics. Park design debates. End with a written commitment. Then check the sprint: if the plan still dies, you only fixed the symptom in the room.

If causes disagree in the room, you do not have a diagnosis yet. Use the last sprint's board as the tie-break: what actually broke the plan. Opinions about “how we are as a team” lose to the tickets that appeared on Tuesday.

Run one change for one sprint. Write it as a PDCA.

Plan. One sentence: “Because [cause], next sprint we will [behavior], and we will call it working if [signal].” Useful signals: fewer items added after Monday; planning ends inside the timebox *and* carryover drops; interrupt hours were reserved and used.

Do. Put the behavior on the calendar or the board before planning starts. If the change needs a new meeting, it is probably too big.

Check. At the next retro, look at the signal only. Ignore whether people “liked” the new rule.

Act. Keep, drop, or shrink the change. Do not add a second experiment until this one has a result.

If the diagnosis was “known interrupts,” reserve a visible interrupt budget in planning and refuse to fill it with feature work. If it was “unready items,” use a cutoff: if it is not ready 24 hours before planning, it is not in the sprint. If it was “the room runs over,” hard-stop and leave unready items out. Do not squeeze them in.

Keep the experiment to one cause and one sprint. At the next retro, use the signal you wrote down — carryover, unplanned tickets, or overrun — not whether the new rule felt better.