Scrum deleted the word “commitment” from sprint scope in 2011. Most teams still plan like it never happened.
It’s right there in the Scrum Guide’s own revision log: “Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done…” That was 2011. The 2020 Guide finished the thought: every Scrum artifact now carries exactly one commitment, and the Sprint Backlog’s commitment is the Sprint Goal — which, in the Guide’s own words, “provides flexibility in terms of the exact work needed to achieve it.”
Unbundle that, because it’s the whole gate: you commit to the goal. You forecast the scope. The goal is the one sentence you’ll stand behind at sprint review; the scope is your best current estimate of the path to it. The scope flexes mid-sprint. That’s the design. The goal doesn’t flex. And the review question changes with it: not “did you finish the tickets?” but “did you reach the goal?”
What does Gate 60 actually check?
Most planning meetings never made the switch. The ticket list gets treated as the promise, the promise meets reality around day four, and the org slowly learns what a broken scope-promise teaches: pad the estimates, distrust the forecast, ask for commitments earlier and harder. Gate 60 in my system — Sprint Commitment — exists to make the commitment the right shape before the sprint starts. Six checks:
Everything pulled meets the Definition of Ready. Gate 50’s receipt, presented at the door. Unready work in a committed sprint isn’t ambition; it’s a carryover with a head start.
Capacity is arithmetic, not ambition. The classic calibration rule is Yesterday’s Weather — Fowler and Beck’s principle that “you should plan to do as much this iteration as you did last iteration.” Last sprint’s actuals, minus this sprint’s realities: the PTO, the on-call rotation, the release week. The Guide says the same thing quieter — the more the team knows about “their past performance, their upcoming capacity, and their Definition of Done,” the more confident the forecast. If the plan needs a heroic sprint to close, the plan is the problem.
One sprint goal, stated, singular. The Guide’s claim is that the goal creates “coherence and focus.” The data points the same way: Verwijs and Russo’s study of Scrum team effectiveness — drawing on thirteen field studies and roughly five thousand practitioners across two thousand teams — puts clear sprint goals among the factors that ride with team effectiveness. It’s correlational, so it corroborates the Guide rather than proving it. A sprint with three goals has none.
A tech-debt buffer that’s a choice, not a superstition. Everyone quotes the same number, so the honest audit goes up front: the number is folklore; the reserve is cost-backed. The evidence, briefly:
- No standard, framework guide, or study prescribes the famous “reserve 20%.” The closest citable source is one practitioner post on Scrum.org suggesting fifteen to twenty percent.
- The cost is real: in Besker and colleagues’ peer-reviewed study, developers report losing 23% of their working time to technical debt on average.
- Stripe’s survey counted 17.3 hours of a 41.1-hour developer week going to debt and bad code — about 42% of the week, by my arithmetic.
- And fixed reserves have precedent at scale: Google’s SRE model caps ops work at 50% so engineering time can’t silently vanish.
So: pick your number, defend it as a management choice grounded in that evidence, review it quarterly. Doctrine won’t hand you the number. The evidence hands you the reason.
Blockers with owners. A dependency flagged without a name attached isn’t identified — it’s scheduled.
A demo you can name. If the team can’t say in one sentence what gets demoed at review, the increment is a hope, not a criterion.
A sprint with three goals has none.
What changed this year?
Now the amplifier, because AI bent this gate in a way most teams haven’t priced in. Yesterday’s Weather assumes the weather is stable — and right now it isn’t. When throughput moves month over month (new tools, new agents, a new workflow every few months), last sprint’s actuals expire faster than they used to. The fix is keeping the rule and widening its error bars: re-baseline every sprint and plan in ranges until throughput settles, honestly and out loud. The sharper problem is social: “AI made you faster” arrives in planning as “so commit to more.” That’s the amplifier working on your promises — inflating them on the same schedule as your tooling. The goal-commitment discipline is the team’s shield: promise the outcome you can defend under questioning; forecast the scope as a range — “we’ll land eight to ten of these twelve,” not “all twelve” — so the error bars are visible instead of implied; let the tickets flex while the goal holds.
Where does AI fit — and where can’t it?
The augmentation runs before planning, same pattern as every gate so far. AI checks each candidate story against the Definition of Ready; sums the estimates against real capacity — arithmetic a model does in seconds and planning meetings routinely skip; flags the dependencies with no owner; and drafts two or three sprint-goal candidates from the selected work. That last one is quietly the best diagnostic in the set: if every goal AI drafts needs an “and” to cover the selection, you didn’t pull a sprint — you pulled a pile. Then the human does the only step that ever mattered: commits. A model can compute a forecast. Only the team can promise.
Why does the engineering leader own this gate?
The forecast is the org’s interface to your team. Every scope-promise that breaks depreciates it, and the org reprices — more padding, more check-ins, less trust. So when leadership says “AI made you faster,” report goals met, and publish the forecast as the range it is. Protecting the shape of the commitment is protecting the team’s word.
What’s the one change worth making?
If you change only one thing after reading this, change the question you ask at sprint review: stop asking “did you finish the tickets?” — start asking “did you reach the goal?” The team hears the difference immediately, and the rest of the gate follows the question.
It’s the same trade as always: promising everything is the easy choice in the planning meeting and the hard life at review. Committing to one defensible goal is the hard conversation today — and the easy life for the next two weeks. Easy choices, hard life. Hard choices, easy life.
That’s Protocol #6. Gate 70 — Code Complete, where “done” starts meaning deployable — is next. Six gates to go.
