Three weeks before a publisher demo, a two-person team I talked to had a task board with 94 cards on it. Forty-one were in "In Progress". Nobody could say which five things had to be true for the demo to exist. The board wasn't a plan — it was a diary of everything anyone had ever thought of.
Small game teams don't fail at production because they lack process. They fail because they borrow a process built for a twelve-person web team with a product owner, and then quietly stop using it by sprint three. What follows is a stripped-down sprint loop sized for two to five people, with the numbers that make it work.
Start with capacity, not with tasks
The first mistake is planning a sprint by picking tasks until the board "looks full". Plan by capacity instead, and be honest about how small that number is.
A two-week sprint has ten working days per person. You will not get ten days of feature work out of any of them. Budget like this:
| Line item | Days per person (2-week sprint) |
|---|---|
| Raw working days | 10 |
| Meetings, planning, playtest session | −1.0 |
| Support work: builds, store page, email, tooling | −1.0 |
| Unplanned bugs and breakage | −1.5 |
| Committed feature capacity | 6.5 |
For a three-person team that's about 19–20 person-days of real planned work per sprint, not 30. If you commit 30, you will carry a third of the board forward every sprint and slowly learn to ignore your own estimates.
Two rules keep that number honest:
- Estimate in half-days, 1, 2, or 3 days. Nothing bigger goes on the board. A 5-day card is not an estimate, it's a confession that the task hasn't been designed yet — split it or spike it.
- Track one velocity number: committed days versus completed days. After three sprints you'll have a personal multiplier. If you consistently finish 14 of 20 committed days, your real capacity is 14. Use 14.
Give every sprint one claim you can test
A sprint goal is not "work on combat". It's a sentence a playtester could confirm or deny at the end of the sprint:
"A new player can complete the mine level using only the grapple and the pickaxe, and dies to the drill-boss at least once."
That phrasing does three useful things. It names the content (mine level), the systems in scope (grapple, pickaxe, boss), and the evidence (someone plays it). Anything on the board that doesn't serve the claim is visibly off-goal, which makes cutting an argument about the sentence rather than about someone's feelings.
One claim per sprint. Two claims means two sprints pretending to be one.
Write it where the board lives — in GameDesignerX, the sprint goal sits on the sprint itself in Task Boards & Sprints, and links upward to the Milestones entry it serves, so you can see which vertical-slice requirement a given fortnight was actually buying.
A five-column board and nothing more
Columns are a model of your workflow. Most indie boards have too many, so cards rot in the middle.
| Column | Entry condition |
|---|---|
| Backlog | Anything, unestimated. Never pulled from directly. |
| This Sprint | Estimated, serves the sprint claim, has a definition of done. |
| In Progress | Someone's name on it. Hard limit: 2 per person. |
| Needs Review | Code merged or asset in engine; waiting on a second pair of eyes or a build. |
| Done | Meets the definition of done, in a build, on the branch. |
The work-in-progress limit of two is the single highest-value rule on this list. When a third card wants to start, you must finish or explicitly park something — and parking is a decision you can see, not a drift you discover in week three.
Definition of done, written once
"Done" is where small teams leak time. Agree on it once, paste it into the board's card template, and stop relitigating:
- Works in a packaged build, not just in the editor
- Controller and keyboard both bound and tested
- No new errors or warnings in the log on the test level
- Placeholder art is labelled as placeholder in the asset name
- Any tuning value lives in a data table, not hard-coded
- Design doc updated if behaviour changed
- Added to the build notes line for this sprint
Seven checkboxes. If a card can't tick all seven, it's in Needs Review, not Done. The "tuning value lives in a data table" line pays for itself the first time a playtest says the grapple is too slow and you fix it in twenty seconds instead of re-exporting a build.
Cards that describe behaviour, not intentions
Compare two cards for the same work:
- "Grapple improvements"
- "Grapple: add 6-frame input buffer before latch; cancel on ledge grab; max rope length 900 units"
The second one can be estimated, reviewed, and tested by someone who isn't you. It also survives three weeks of memory loss. A good card has the numbers in it, because the numbers are the design. If you don't know the numbers yet, the card is a spike: "Spike: find grapple rope length that makes the mine's second gap reachable — 1 day, output is a number and a video."
Timeboxed spikes are how design uncertainty enters a production board without poisoning it. The deliverable of a spike is a decision, so log it — GameDesignerX's Decision Log is the natural home — and then write the real card.
The three rituals you actually need
Drop everything else.
- Sprint planning — 45 minutes, every other Monday. Review last sprint's committed-versus-completed number, write the claim, pull cards until you hit capacity. Stop pulling. Leave the rest in Backlog.
- Twice-weekly standup — 10 minutes, Tuesday and Thursday. Three questions, one of which most teams skip: What moved? What's blocked? What should we cut? Asking the cut question twice a week normalizes scope reduction as routine hygiene instead of a crisis.
- Sprint review — 60 minutes, Friday. Play the build against the claim, with an outsider at the controls if you can get one. Then do carry-over triage.
The carry-over rule
Every card that didn't finish gets exactly one of three verdicts, and the third one is mandatory:
- Re-commit — genuinely nearly done, carries once.
- Re-scope — split into something that fits the real capacity number.
- Cut — back to Backlog, or deleted.
Any card that carries twice must be re-scoped or cut. It cannot carry a third time. That one line is what stops a board from accumulating 94 cards. A task that has survived two sprints without finishing is telling you it's badly understood, not that you need to try harder.
What the board is for
The point of all of this isn't tidiness. It's that six weeks from now you'll need to answer a hard question — can we ship the demo in March? — and the only honest input is your own history: three sprints of committed-versus-completed days, a carry-over list, and three sprint claims that either came true or didn't.
That's a forecast. Ninety-four cards and a vibe is not.
Start next Monday. Write one claim, budget 6.5 days a person, cap work-in-progress at two, and enforce the carry-over rule. You can add process later if you ever actually miss it.