Summary
A user story is a short description of a game feature (or tool/pipeline feature) expressed from the perspective of the user who benefits from it. User stories are the primary format for items in the Product Backlog. They replace the discipline-internal task descriptions that cause communication breakdowns between designers, programmers, artists, and stakeholders.
The key insight: the language of the player must be the universal language of game development. A story expressed in player terms is understandable by every discipline — and by the publisher or stakeholder who must prioritise it.
Key ideas
The user story template
As a <user role>, I want <goal> [so that <reason>].
- User role — who benefits (player, animator, prop modeller, level designer)
- Goal — the feature or function
- Reason — the benefit when this feature is used (optional when obvious)
Game feature examples:
As a player, I want a mute player button so that I stop being distracted
by other players online.
As a player, I want to see my health level.
As a player, I want a double-jump so that I can reach elevated platforms.
Pipeline/tool examples (the developer is the user):
As an animator, I want to change animations directly in the game without
restarting it so that I can iterate faster.
As a prop modeller, I want the exporter to check naming conventions so that
a poorly named prop does not crash the game.
Tool and pipeline stories are valid Product Backlog Items. Developer productivity is a legitimate value target.
Levels of detail: stories, epics, themes
Stories too large to complete in a single Sprint are called epics. Groups of related stories form a theme. Some projects add a saga above epic for the broadest scope.
Theme: Online multiplayer
Epic: Online lobby
Story: As a player, I can see other players in a lobby before a match.
Story: As a player, I can invite a friend to my lobby.
Epic: Online gameplay
Epic: Deathmatch
Story: As a player, I want to respawn after being eliminated.
Story: As a player, I want to see a kill feed.
Only high-priority stories need to be sprint-ready. Lower-priority epics remain coarse until they rise in priority — splitting prematurely wastes effort on work that may never happen.
INVEST criteria
Good user stories satisfy INVEST:
| Criterion | Meaning | Game example |
|---|---|---|
| Independent | Avoidance of ordering dependencies between stories | ”Player can jump” should not require “Player can run” to be done first |
| Negotiable | Details are discussed, not locked in the story card | The exact jump height is decided in conversation, not specified on the card |
| Valuable | Delivers value to a user | ”Implement jump state machine” fails; “Player can jump” passes |
| Estimable | The team can form a reasonable size estimate | If nobody can estimate it, it needs clarification or splitting |
| Sized appropriately | Small enough to complete within a Sprint | Epics fail this; split them |
| Testable | Acceptance criteria can be defined | ”Player can jump” needs: jump reaches X height; responds within Y ms |
Acceptance criteria
Acceptance criteria define when a story is “done” — they make the story testable and resolve design ambiguity before implementation begins.
Example:
Story: As a player, I want to see my health level. Acceptance criteria:
- Health bar visible in HUD during gameplay
- Updates immediately when damage is taken
- Shows 0 when the player dies
- Does not obscure critical gameplay area
Written collaboratively by designer, programmer, and QA. Acceptance criteria become the Definition of Done for that specific story (see Definition of Done).
Story splitting strategies
Large epics must be split into sprint-sized stories before implementation:
- Along research/prototype dependencies — split out a spike (research task) first when uncertainty blocks estimation
- Along conjunctions — “player can jump AND double-jump” → two stories
- By progression or value — ship a basic version first, enhance in subsequent stories
- By user roles — different users want similar features for different reasons; split by role
Story points and velocity
Story points are a relative measure of a story’s size and complexity — not a duration estimate. The team agrees on a reference story and estimates others relative to it.
Fibonacci scale (most common): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
- Closely spaced at the low end (where precision is possible)
- Widely spaced at the high end (where precision is not)
- Stories estimated above the highest value should be split before estimating
“It’s better to be ‘roughly right’ than ‘precisely wrong.’ Your range of accuracy cannot exceed your range of certainty.” (Mike Cohn, via Keith)
Velocity is the number of story points a team completes per Sprint, averaged over several Sprints. Used to forecast release dates: remaining backlog ÷ velocity = sprints remaining.
Rule: velocity is only meaningful for the team that measured it. Cross-team comparisons are meaningless and counterproductive.
Planning Poker
A structured group estimation technique:
- Moderator reads a story
- Each team member selects a point card privately
- All reveal simultaneously
- Outliers explain their reasoning — exposing hidden assumptions
- Discuss; re-vote
- Repeat until convergence
Do not average the votes. Divergence contains information about unresolved uncertainties that must be discussed, not arithmetically smoothed away.
In practice
In Unity projects, user stories map well to feature-level scope — something completable in a sprint that produces something a player can see and interact with.
Good: As a player, I want enemies to patrol a route so that the level feels alive.
Poor: Implement EnemyPatrolBehaviour.cs — this is a task, not a story. It describes implementation, not value.
Stories for tools are legitimate and often neglected:
- As a level designer, I want to place triggers in the Unity editor without writing code.
- As an artist, I want the build to report missing textures with file paths, not just “error.”
Evidence
“A user story is a short description of a game, tool, or pipeline feature that has a clear value to a user.” (Keith, Ch. 8)
“User stories represent the requirements of the game from the point of view of the user, not the developer. They don’t fully describe design details. Stories are placeholders for conversation about the details.” (Keith, Ch. 8)
“Don’t average the votes. The different point estimates often hide what needs to be discussed! Assigning an average doesn’t solve potential problems with the story.” (Keith, Ch. 9)
Implications
- If a story cannot be estimated by the team, it contains unresolved ambiguity — more conversation (not more documentation) is the fix
- A backlog written entirely in implementation terms recreates the design document problem
- The “so that” clause prevents the team from optimising the implementation while missing the player intent
Open questions
- User stories were designed for software teams; do they need adaptation for art-heavy or narrative-heavy game projects?
- How should teams handle stories with very long lead times (e.g. motion capture sessions requiring months of advance booking)?
- Is Planning Poker still the best estimation technique for very small teams (2–3 people)?
Related
product-backlog | sprints | scrum-in-game-development | agile-design | overview-agile-game-development | source-agile-game-development