Scope creep hides in the words
I had frozen my game's scope. Then I wrote a roadmap that, without ever lying, had relabeled as "finishing" work I'd filed away for after release. The quiet mechanics of scope creep, and the document that stopped me.
My roadmap could no longer tell finishing from growing
At the end of June, I had frozen my game's design document. Frozen means locked: no change without a written decision. Inside it, a clean border. On one side, the 1.0 scope: one ship, one boss, the station. On the other, a list explicitly stamped "after 1.0": extra bosses, a second ship, the English translation.
A few days later, I wrote a roadmap titled "the path to 1.0". Reading it back, I could no longer tell whether it finished the game or made it bigger. The extra bosses, the second ship, the translation: all there, all repainted "toward 1.0". Not a single line lied. Each one was reasonable. And yet the whole thing had quietly swallowed part of what my frozen document had filed away for later.
"Finish" and "grow" look too much alike
The problem isn't bad faith, it's vocabulary. In roadmap prose, "finish the game" and "grow the game" are written with the same verbs: add, complete, enrich, polish. A second ship "rounds out the offering". Extra bosses "beef up the ending". Translation "widens the audience". Every expansion tells itself as a finishing touch.
That's scope creep, the silent stretching of the boundary: rarely a big decision you own, almost always a string of rewordings that never present themselves as additions. For my title, the context made the drift absurd: 16 downloads, 0 followers. No signal was asking for more content. And my own roadmap still floated several post-1.0 projects dressed up as the home stretch.
The fix: a document that says no for me
An audit of the plan (five reviewers and one arbiter) named it: the roadmap was relabeling post-1.0 content with no amendment, no costing, no cutoff. The fix wasn't "be more careful". Distrusting yourself doesn't hold up over time. I put the frozen document back at the center and set three simple rules.
The word that matters is "before". A reintroduction dated before the commit (the record of a change in the code's history) leaves a trace; a decision made in the heat of implementation leaves none. The document doesn't make me more disciplined, it forces me to write my decision where I'll read it again, instead of letting it dissolve into a roadmap sentence.
- The "out of scope" list stays frozen. It doesn't move just because a roadmap talks about it nicely.
- Every item in the plan is checked against that list, one by one. If it's on the list, it's out of 1.0. Full stop.
- Bringing an item back requires a written line, dated, BEFORE the first line of code. Not after, not "we'll see".
Anywhere a spec is frozen
The trap has nothing to do with video games. It springs the moment an action plan sits next to a frozen spec (the scope decided once and for all) and you let the first comment on the second. A product backlog (the list of pending work), a client project's task list, a personal roadmap: anywhere you can relabel an item without amending the reference, expansion disguises itself as finishing.
The fix is always the same, and it's boring: make reintroduction expensive by making it explicit. One line. Dated. Before the code. It isn't willpower that holds the scope, it's the act of writing down, in black and white, that you're stepping outside it.