§ 89
Fixed Time, Variable Scope
When scope is fixed and time is not, the date slips and the scope stays; fixing the time instead forces a choice about what matters.
Keep in mind
Decide what the work is worth before you ask how long it takes
What to do
Before the work starts, decide how much time it is worth, not how long it will take, and shape the scope to fit. When the time runs out, stop by default: ship what is done if it stands on its own, otherwise reshape it and decide afresh whether to bet on it again; do not quietly extend. Cut features before tests or review, and do not fix the time on work that cannot be sliced below a coherent minimum.
Why it happens
An estimate starts from a design and ends with a number, and the number is usually wrong in the same direction because the unknowns only surface once the work is under way. When the date slips, the scope stays, since every item already has an advocate and asking for more time feels cheaper than cutting something. Fixing the time first (what Shape Up calls the appetite) turns the question from "how long will this take" into "what is the best version we can ship in this much time", so cutting scope becomes the normal move rather than an admission of failure. An overrun project that keeps getting extensions is the same force again, now fed by sunk cost.
When it stops applying
Quality as the Hidden Variable: under a fixed date a team that cannot or will not cut scope cuts tests, review and error handling instead, and some work (a protocol, a compliance requirement) has a floor below which no slice is worth shipping.
Source
Ryan Singer, Shape Up (Basecamp, 2019), ch. 3 "Set Boundaries" — the appetite and "fixed time, variable scope"; ch. 8 "The Betting Table" — the circuit breaker: "by default the project doesn't get an extension". Earlier, 37signals, Getting Real (2006), "Fix Time and Budget, Flex Scope": "Never throw more time or money at a problem, just scale back the scope."
Read the sourceCite this
Hammurabi, § 89, “Fixed Time, Variable Scope.” https://kanywst.github.io/hammurabi/laws/fixed-time-variable-scope/
BibTeX
@misc{hammurabi-fixed-time-variable-scope,
title = {Fixed Time, Variable Scope},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 89},
url = {https://kanywst.github.io/hammurabi/laws/fixed-time-variable-scope/}
}Read in a column
- Why estimates slip Next in the column: Cost of Delay
Related laws
- 40Parkinson's LawWork expands to fill the time available for it.
- 13Hofstadter's LawWork takes longer than estimated, even when the estimate already allows for that.
- 16Sunk Cost FallacyTeams keep funding a failing project because of what they have already spent on it.
- 92Technical DebtCode shipped before the team fully understands the problem charges extra on later changes to that code until someone rewrites it.
- 107Cost of DelayWork gets ordered by size, by gut feel or by whoever asks loudest, while what each item loses every week it waits goes uncounted, so the most valuable work often waits behind the merely visible.