Skip to content
← All writing

Sprint commitment vs forecast: the argument is at the wrong level

· 6 min read · by Tan Gravam

The short answer

Scrum renamed the sprint commitment a forecast in 2011, and at ticket level that was right: two weeks of task-level work is genuinely a forecast, and punishing teams for missing it produced padding, not predictability. The mistake is concluding the organisation can run on forecasts alone. One level up — where people, budget and dates are promised to someone — a commitment is exactly what is being made, whatever it is called, and softening the word does not soften the promise. Keep forecasts at sprint level, and make the real commitments explicit at the demand level: owned, sized by the delivering team, dated, and closed against what was promised. The dysfunction was never the word. It was applying it at a granularity where it could not be honoured.

In 2011 the Scrum Guide quietly swapped one word: the sprint commitment became the sprint forecast. Fifteen years later the argument is still running, which is usually the sign that both sides are right about different things — and that the interesting question is hiding one level up.

Why the rename was correct

At ticket level, a sprint plan genuinely is a forecast. Two weeks of task-level work involves discovery, interruptions, and estimates made at the moment of least information. Calling that a commitment — and then treating a miss as a broken promise — produced exactly what you would predict: padding. Teams learned to under-plan, split stories defensively, and negotiate scope down before saying yes to anything. The word intended to create accountability created sandbagging, because it demanded a promise at a granularity where honest promising is impossible.

So the renamers were right: punish sprint-level misses and you do not get predictability, you get estimates hardened into dates plus a safety margin nobody will admit to.

Why the conclusion drawn from it was wrong

The mistake is the next step many organisations took: if sprint commitments are unhealthy, commitments are unhealthy — the whole enterprise runs on forecasts now, and nothing is ever promised. Except it is. Somewhere above the sprint, people, budget and dates are being promised to customers, to boards, to other teams — in contracts, in QBRs, on slides. Renaming the sprint artifact did not make those promises go away; it made them unrecorded, because the vocabulary for promising was retired while the promising continued.

That is the worst of both worlds: the organisation carries real commitments and keeps no ledger of them. When one slips, nobody can reconstruct what was actually agreed, by whom, on what evidence — the slip was decided at commitment time, and commitment time left no record because officially it never happened.

Two levels, two words, both honest

Sprint level: forecast. The team's own planning instrument, calibrated against its own history, read by nobody outside. Misses are information, not failures. Scrum got this right; leave it alone.

Demand level: commitment. The unit at which someone outside engineering is being promised something. Here the word must be the strong one, and it must come with the strong word's obligations: a readiness bar before the promise — owner, team-given capacity, dependencies, unknowns written down — a recorded exception when promising early anyway, and an honest close against what was promised.

The two levels do not compete, because they answer different questions. The forecast answers "what does the team expect to finish?" The commitment answers "what did we promise, and was it kept?" An organisation needs both answers, and no single word can carry both without corrupting one of them.

The test for which word you need

Ask who reads the number. If the only readers are the team itself, it is a forecast — protect it from outside eyes and let it be wrong in both directions. If anyone outside the team plans against it, spends against it, or repeats it to a customer, it is a commitment whatever you call it — and the honest move is to call it one and give it a record. The dysfunction was never the word. It was applying it at a granularity where it could not be honoured — and then, in the correction, retiring it from the granularity where it must be.

Where DeliverySheet sits

The product deliberately has no sprints, story points or burndown — sprint altitude belongs to the team and its tracker. What it holds is the demand level: the commitment as a first-class, recorded act with a bar in front of it and a close behind it. If your retrospective on this debate is "we renamed commitments to forecasts and our dates still slip", the missing piece was never inside the sprint.

I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.

$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.

More on deciding what to commit to

Read the overview: How to decide what to commit to →