One level, finished, before ten levels blocked out
A finished slice tells you what a level costs. Ten grey boxes tell you nothing and feel like progress, which is the dangerous combination.
Pro edition
Scope Sheet.
The demo publishes a cut list. This is where one comes from — the questions asked before a feature is built, so the cutting happens on paper in week two rather than in the engine in month nine. None of it is a methodology. It is five habits that between them decide whether a project has a release date.
A feature is never just its code
The code is 30% of a feature. Estimate it honestly, then multiply by 3.3.
- The code 30%
30% of a feature The part everybody estimates, and usually the only part. It is under a third. - Tools and editor 15%
15% of a feature Anything a designer has to author needs a way to author it. Skipping this is how a feature becomes a programmer bottleneck for a year. - Art and audio 20%
20% of a feature Not your hours, still your schedule. A feature that needs forty new assets is a feature that needs an artist to have finished something else. - Integration 15%
15% of a feature Save/load, settings, localisation, input remapping, controller support. Every feature pays this tax and no estimate includes it. - QA and fixing 20%
20% of a feature The long tail. This is the share that gets eaten by the release date and it is why "it works" and "it ships" are eight weeks apart.
Estimate the code honestly, then multiply. If a system is two weeks of code, it is closer to six weeks of feature — and a team that consistently forgets this does not have an estimation problem, it has an arithmetic one.
3 questions that kill a feature early
-
01
What does this replace?
A feature that adds without replacing anything is a feature that adds surface area. If nothing gets simpler, ask again what it is for.
-
02
What is the cheapest version that tests the idea?
Twelve hand-built wrecks tested the same hypothesis as a procedural generator, in a fortnight instead of nine weeks. The cheap version is not a prototype of the real one — very often it IS the real one.
-
03
What happens if it is simply not there?
The most useful and least asked. Half the features on any wish list survive only because nobody has said the sentence "we ship without it" out loud.
The vertical slice rule
Ship the pipeline before the content
If putting an asset in the game takes an engineer, you do not have a pipeline, you have a bottleneck with a person in it.
The slice includes the boring parts
Save/load, pause, settings, a real main menu. A slice without them is a demo, and demos hide exactly the work that overruns.
Play it in front of somebody in week four
Not for feedback on the idea — for the fact that you cannot lie to yourself while somebody else is holding the controller.
When to cut the date instead
| Situation | What to cut |
|---|---|
| The core loop is not fun yet | Cut the date. No amount of feature cutting fixes a loop, and shipping on time with a loop that does not work is the most expensive possible outcome. |
| The cut list is down to things you would put back | Cut the date, once, by a real amount. Cutting features you will immediately re-add post-launch is just moving the work and losing the momentum. |
| Scope is stable and the date is external | Cut features. This is the normal case and it is what the whole sheet is for. |
| You have moved the date twice already | Neither. Stop and re-scope the project rather than the release, because at this point the plan is wrong rather than the estimate. |
6 ways a project loses its date
- The code estimated and the other 70% forgotten, so every feature lands at three times its number.
- Ten levels blocked out and none finished, so nobody knows what a level costs until month eleven.
- A tools pass deferred, and a designer waiting on an engineer for every content change for a year.
- Features cut in the engine at month nine instead of on paper at week two, at forty times the cost.
- A release date moved three times, each time by two weeks, because nobody would move it once by three months.
- No written cut list, so the same rejected feature is re-proposed every quarter by somebody new.
Percentages are one developer's observed split across two shipped titles and three that stopped. They move with team size and genre — a multiplayer title pays a far larger integration tax — but the shape holds: the code is the minority of the work.