Deadline-Backward Scoping
Fit the work to fixed time, then cut relentlessly as the deadline nears
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 98%
Work backward from the available time and the team's demonstrated capability, not forward from an unconstrained wish list. Romero says id Software's founders had each spent roughly a decade making games, so they knew how quickly they could program, draw, animate, design levels, and build tools. They used that knowledge to define exactly how large a game could be if it had to ship in two months. Once defined, the scope was protected from additions and reduced whenever delivery risk rose. The mechanism combines calibrated estimation with active subtraction: experience tells the team what is feasible, a fixed deadline creates a boundary, and deliberate cuts keep the project inside it. Repeating the cycle improves the team's understanding of its real throughput and makes future scoping faster and more reliable.
Origin
Extracted from The Tim Ferriss Show, where John Romero explains how id Software completed 13 games in 1991.
Core principles
- 01Time and team capability define the feasible scope
- 02A stable boundary enables fast execution
- 03Finishing requires subtraction
- 04Repeated delivery improves estimation
How to run it
- 1
Fix the delivery boundary
Set the amount of time available and treat it as a design input. Do not begin with an unlimited feature list.
Pro tip Use a deadline short enough to force clarity.
- 2
Calibrate team capacity
Use completed work to estimate how fast each contributor can execute. Include invisible work such as tools, packaging, and production infrastructure.
Pro tip Base estimates on demonstrated delivery, not optimism.
Watch out Ignoring supporting work creates a falsely generous scope.
- 3
Define the complete game
Specify the smallest coherent product the team can finish inside the boundary. Decide what it includes and what it will not include.
Watch out An incomplete collection of features is not a small complete product.
- 4
Stop adding
Hold the agreed boundary while execution proceeds. New ideas wait unless they replace work of equal or greater cost.
Watch out Late additions spend the margin needed for inevitable delivery friction.
- 5
Subtract to ship
As the deadline approaches, remove lower-value elements that threaten completion. Preserve the coherent core rather than extending the date by default.
Pro tip Pre-identify the easiest features to cut.
In the wild
The four-person id Software team worked on two-month game cycles and sometimes developed two games at once. Their long individual histories of making complete games let them estimate their capabilities, define a feasible size, and remove unnecessary work as deadlines approached.
→ The team made 13 games in 1991.
Common mistakes
Scoping from desire
Starting from every desirable feature ignores the capacity and time that actually determine what can ship.
Adding after commitment
Continual additions destroy the stable target that lets a small team execute quickly.
Protecting every feature
Refusing to subtract as the deadline nears turns a fixed schedule into missed delivery or unsustainable work.
Is it for you?
Best for
It is best for experienced teams delivering bounded products on short, non-negotiable schedules.
Not ideal for
It is not ideal for exploratory research whose essential solution cannot yet be defined.
From the transcript
“And when you make that many games that quickly, you learn how to scope, and scoping is basically defining exactly what that game should be…”
“So we had to know how good every one of us is, how fast we can all work, and then scope a game to that…”
“We knew what to cut when it was time to start cutting stuff if we're getting closer to our deadline.”
From the episode
#681: Doom Legend John Romero — The Path to Prolific Innovation and Making 130+ Games, How to Find the Soul of the Work, Audacious Ambition, and Building in Monk Mode
John Romero