BP #8: Definition of Done
Define what “done” means for the game before a single line of code is written. Write it at concept lock. From that point it ends every argument about what to add or fix.
Done = a playable, coherent experience that communicates the core idea.
Not “all features complete.” Not “polished.” Not “as good as it could be.”
Why It Works
Without a shared definition, “done” expands to fill whatever time is left. There is always one more thing to fix, one more thing to polish. Burning Light spent six hours correcting a math bug during LD36 that did not affect gameplay in any way the player would notice. [1] The developer was chasing an internal standard rather than a shippable game. Six hours gone.
That is what happens when the target is undefined. Effort flows toward invisible quality criteria while actual submission readiness gets pushed back.
The Definition of Done makes the target concrete and shared. When someone argues for more time on something, one question settles it: does this get the game closer to done, or is the game already done and the team is optimizing past it?
Writing Your DoD
At concept lock, answer: what does a shippable version of this game look like?
Four things that belong in every jam DoD:
- Player can start, play and reach an end state without breaking
- Core mechanic is functional and responds to input
- Win/loss condition is clear
- Game communicates its concept without verbal explanation
That is the full list. Anything beyond this is polish. Polish is not done.
Using It
Hour 36 arrives and the team is debating what to work on. The DoD decides. Everything that serves it gets time. Everything that does not gets cut.
It also protects against perfectionism consuming the hours that should go toward submission. One developer fixing a system that works fine is one developer not finishing the game. [NoEvidence] The DoD is the thing you point to when that happens.
Methodology Connection
Methodology Connection
Scrum defines “done” as a written team agreement on what complete means for a deliverable. In Scrum this applies at the story level. At 48-hour scale it applies to the whole game. The function is the same: a shared, explicit target that stops scope from drifting outward whenever someone has an idea for what else could be added.
Related
- AP #6 — Perfectionism: DoD is the fix
- BP #6 — Pivot Gate at Hour 24: DoD guides cut decisions at the gate
- BP #7 — Playtesting Checkpoint: validates whether DoD is actually met