Summary
The Product Backlog is an ordered list of everything that needs to be built into the game — features, content, tools, pipeline improvements. It replaces the design document as the primary planning artefact in Scrum. Unlike a design document, it is ordered by value rather than by category or discipline, is continuously updated as knowledge grows, and deliberately defers detail to the point it is needed.
Key ideas
Why design documents fail
Keith’s Smuggler’s Run incident is the canonical failure case: a feature (wandering animal herds) was added to page 97 of the design document mid-project; the lead programmer had not re-read it and did not know the feature existed until two weeks before alpha.
Design documents fail structurally because they:
- Fail to communicate feature value — each team member evaluates priority independently based on their own discipline’s concerns
- Cannot capture change — documents are poor change-tracking databases; updates get missed
- Create false certainty — specifying everything up front gives the impression of knowledge that does not yet exist
- Are often not read — Keith recounts inserting a SpongeBob SquarePants appearance into the design document of an M-rated game as a test; the publisher never commented
The problem is not that designers write carelessly. The problem is that monolithic documents are the wrong tool for communicating evolving, cross-discipline, value-ordered requirements.
The Product Backlog
A Product Backlog is an ordered list of Product Backlog Items (PBIs) — features, content, tools, or improvements — that describe the game as it is currently understood.
Properties:
- Ordered by value/cost/risk — the most important items are at the top
- Expected to change — every Sprint Review updates the backlog based on what was learned
- Hierarchically detailed — top items are small enough to complete in one Sprint; items deeper in the list remain as epics until they rise in priority
Example backlog (platform game, ordered):
Jump ← Sprint-ready
Crawl ← Sprint-ready
Fly ← Sprint-ready
...
Online ← Epic: split when priority rises
Map Editor ← Epic: split when priority rises
Lower-priority items are left as epics deliberately — splitting them prematurely creates a false sense of detail and a backlog too large to manage.
Why this ordering matters
“Delivers potentially deployable features in value-first order: Features are built in the order of the value they add for the players who buy the game. Delivering the highest-value playable features ahead of lower-value ones drives the development of the game rather than a preset ordered list of work. This enables the true value of the game to emerge earlier, when we can make better decisions about its direction.” (Keith, Ch. 7)
Backlog refinement
Backlog refinement (also called grooming) is a regular meeting (typically mid-sprint, 1–2 hours) where the team and Product Owner:
- Clarify and split upcoming PBIs
- Re-estimate stories whose context has changed
- Remove items that are no longer valuable
- Add newly discovered items
Refinement ensures the top of the backlog is always sprint-ready. Roughly 10% of a team’s time goes to refinement.
Backlog ordering techniques:
- Risk reduction — prioritise the riskiest, most uncertain features first to remove uncertainty early
- Value/effort ratio — highest value for lowest cost rises to the top
- Story mapping — arrange stories along a user journey to reveal gaps and dependencies
- Kano model — distinguish basic expectations, performance factors, and delighters
Definition of Done
The Definition of Done (DoD) is a shared agreement between the team and the Product Owner about what “complete” means for a sprint item. Without it, “done” means something different to every discipline:
| Discipline | Informal “done” |
|---|---|
| Programmer | ”The feature compiles and runs” |
| Designer | ”The design intent is implemented” |
| QA | ”No known critical bugs” |
| Producer | ”Stakeholders have signed off” |
A DoD makes this explicit. Example Sprint DoD:
- Feature implemented and integrated into the main build
- All acceptance criteria from the user story met
- No new critical bugs introduced
- Asset LODs and performance budgets met
- Code reviewed and in source control
Types of debt
When DoDs are violated — even partially — debt accumulates:
- Design debt — features partially implemented; design decisions deferred
- Technical debt — code that works but degrades maintainability
- Production debt — assets in placeholder state at sprint end
Managing debt: Keith recommends allocating explicit backlog items for debt reduction rather than hiding it in estimates. Debt that is invisible cannot be managed.
Dysfunctional Product Owner archetypes
| Type | Problem |
|---|---|
| Proxy PO | No real authority; decisions must escalate; blocks the team |
| Committee PO | Decisions made by group consensus; slow and contradictory |
| Silo PO | Optimises for one discipline’s priorities rather than the whole game |
| Attention Deficit PO | Constantly changes priorities mid-sprint; destroys predictability |
| Tunnel Vision PO | Ignores player feedback; overrides Sprint Reviews with preset ideas |
| Distant PO | Unavailable for refinement and questions; backlog stagnates |
In practice
For Unity projects, the Product Backlog maps naturally to a tool like Trello, Jira, or Hack n Plan.
A good PBI for a Unity game:
As a player, I want a double-jump so that I can reach elevated platforms.
A poor PBI:
Implement PlayerController jumping state.
The poor version describes implementation, not value. The team cannot prioritise it against other features without inferring the value themselves — which recreates the design document problem.
See user-stories for the full user story format used to write PBIs.
Evidence
“What we need is a planning method that communicates the order and value of features […] enables change and communication of change […] is a placeholder for future communication [and] enables details to emerge as more information is learned.” (Keith, Ch. 7)
“The Product Backlog is not meant to be a detailed list of every feature we may need; that makes it too cumbersome to manipulate. Instead, the PBIs on the top of the list are split, or broken down into small enough features for the team to implement in one Sprint.” (Keith, Ch. 3)
Implications
- The Product Owner role requires genuine authority; a PO who cannot make binding decisions is not a PO
- The “living design document” used as a workaround in many studios still has all the same communication failures as a static document — the Product Backlog is not a living document, it is a prioritised queue
- Keeping the backlog to a manageable size (100–200 items for most teams) requires discipline; backlogs that grow to thousands of items become unmanageable
Open questions
- How should student projects define their DoD when QA and polish time are constrained by deadlines?
- When a studio’s publisher controls release dates, how much influence can a Product Owner realistically have over backlog ordering?
- How does backlog management change for live games with ongoing player-driven feature requests?
Related
scrum-in-game-development | sprints | user-stories | agile-design | minimum-viable-game | kanban-for-game-dev | overview-agile-game-development | source-agile-game-development