Summary
Scrum is an iterative, incremental framework for managing complex, uncertain work. In game development, its core value is matching process to reality: games cannot be fully specified up front, because what is fun only becomes known through play. Scrum replaces the illusion of comprehensive planning with structured empiricism — short cycles, visible progress, and continuous adaptation.
Clinton Keith introduced Scrum to the game industry around 2003 and the framework, along with its companion Kanban, has become the most widely used approach in professional studios (Keith, Agile Game Development, see source-agile-game-development).
Key ideas
Why Scrum suits game development
Traditional plan-driven (waterfall) development assumes requirements can be known up front. Game development breaks this assumption: the fun emerges through iteration, not specification. Detailed design documents fail because they:
- Fail to communicate relative feature value — every team member evaluates priority independently
- Cannot capture change effectively — updates get missed
- Create a false sense of certainty that defers rather than solves problems
Scrum’s answer: deliver a potentially shippable game at the end of every Sprint. Stakeholders play it. You learn. You adjust.
The five values of Scrum
| Value | Meaning |
|---|---|
| Focus | Work on a few things at a time; deliver value sooner |
| Courage | Take chances and create real change because you are trusted and supported |
| Openness | Be transparent about work and concerns so problems surface quickly |
| Commitment | Commit as a team to the Sprint Goal — not as individuals to task lists |
| Respect | Share successes and failures; help each other grow |
The six principles of Scrum
| Principle | In practice |
|---|---|
| Empiricism | Inspect-and-adapt cycle using actual data (daily scrum, velocity, burndown) |
| Emergence | Game features emerge from playing them, not from documents; Sprint Review maximises this |
| Collaboration | Team, stakeholders, and players interact continuously |
| Timeboxing | Fixed cadence (Sprints) enables synchronisation and steering |
| Prioritisation | Develop features by value to the player, not by document order |
| Self-organisation | Small cross-discipline teams manage their own process within constraints |
Scrum roles
The Scrum Team consists of three roles:
Development Team (5–9 people)
- Cross-discipline: programmers, artists, designers, QA
- Self-managing: selects Sprint work, organises its own plan
- Collectively responsible for the Sprint Goal — no individual blame
Scrum Master
- A servant-leader who removes impediments and protects the team’s process
- Not a project manager — does not assign tasks or control schedules
- Facilitates ceremonies; coaches the team on Scrum values
- Acts as a shield between the team and external disruption
Product Owner
- Owns the Product Backlog: orders it by value/cost/risk
- Single person with authority to accept or reject Sprint output
- Represents stakeholders and players, not just business interests
- Common dysfunctions: Proxy PO (no real authority), Committee PO (paralysis by consensus), Tunnel Vision PO (ignores player feedback), Distant PO (unavailable)
Cross-discipline teams
Discipline-siloed teams create unsynchronised priorities — programmers build speculative architectures for features designers may cut; art and code diverge for weeks. Cross-discipline Scrum teams solve this by sharing one Sprint Goal, one priority order, and one daily stand-up.
Key insight: synchronised prioritisation across disciplines. A programmer on a cross-discipline team works on “the player can jump” — not on “an animation state machine that will support future movement types.”
The generalising specialist concept: everyone should be “a game developer first, a specialist second.” A programmer who can help an animator with a broken exporter is more valuable to the Sprint Goal than one who works exclusively within their specialism.
Keith’s “Sean” story illustrates this: the programmer every other programmer dismissed as weak was the one the animators specifically requested — because he dropped anything to fix their exporters and tools. He was keeping an entire team productive.
In practice
Scrum ceremonies at a glance
| Ceremony | Duration | Purpose |
|---|---|---|
| Sprint Planning | 2–8 hrs | Select Sprint Goal; break PBIs into tasks |
| Daily Scrum | 15 min (timebox) | Share progress; surface impediments |
| Sprint Review | 1–4 hrs | Play the game with stakeholders; update backlog |
| Retrospective | 1–2 hrs | Improve how the team works together |
A Sprint in sequence
- Sprint Planning — Team selects a Sprint Goal from the top of the Product Backlog and breaks selected PBIs into tasks
- Sprint execution — Team self-organises; Daily Scrum keeps impediments visible daily
- Sprint Review — Stakeholders play the game; the backlog is updated based on what was learned
- Retrospective — Team improves one or two process items before the next Sprint
See sprints for the full sprint lifecycle.
Evidence
“Sprints produce vertical slices of functionality; they are like mini-projects themselves. A Sprint contains design, coding, asset creation, tuning, debugging, and optimisation — everything necessary to produce a potentially shippable game.” (Keith, Ch. 3)
“At the heart of Scrum is the interaction of the team. […] They own the goal. It’s a team effort. […] A structured, militant environment will never create a team. A team works together toward a shared goal. A group works together toward a goal given to them.” (Shelly Warmuth, quoted in Keith, Ch. 5)
“Ultimately, everyone on the team should be a ‘game developer’ first and a designer/programmer/artist/tester second. A problem with the game is the team’s problem, not just the problem of a single specialist.” (Keith, Ch. 5)
Implications
- A team that is not producing a working build every Sprint is doing mini-waterfall, not Scrum
- The Product Owner must have genuine authority; a “Proxy PO” breaks the feedback loop between value decisions and development
- Cross-discipline teams require cultural change, not just structural change
- Scrum makes problems visible faster; this can feel like Scrum is causing problems. It is not — it is surfacing problems that were always there
Open questions
- At what team/project scale does pure Scrum need supplementing with frameworks like LeSS?
- How do student teams (2–4 people, 12-week semester) adapt Scrum — which ceremonies add value at that scale?
- Does the Scrum Master role make sense for small indie teams, or does a rotating role work better?
Related
sprints | product-backlog | user-stories | kanban-for-game-dev | agile-design | minimum-viable-game | overview-agile-game-development | playtesting | prototyping | source-agile-game-development