Sprints

Summary

A sprint (also called an iteration) is the fundamental unit of work in Scrum. It is a fixed-duration timebox — typically one to three weeks — during which a cross-discipline team designs, codes, creates assets, tunes, debugs, and polishes a set of features to produce a potentially shippable version of the game. The sprint is the heartbeat of an Agile game project.

Key ideas

The sprint goal

The Sprint Goal is the single unifying objective of a sprint — the theme that ties together the features the team commits to delivering. It is usually expressed as a player-facing outcome:

“The player can navigate a representative level where they run, jump, and swim.”

The Sprint Goal:

• Is determined collaboratively in Sprint Planning
• Remains unchanged for the duration of the sprint
• Provides a reference point for deciding whether to cut features mid-sprint if time runs short
• Is the criterion against which the Sprint Review evaluates success

Sprint length

Length	Best for
1 week	Rapid prototyping phases; high uncertainty; small teams
2 weeks	Most game development teams; balanced feedback cycle
3 weeks	Larger teams with significant art/audio content per sprint

Shorter sprints mean faster feedback loops but more planning overhead. Two weeks is the most common default.

Sprint ceremonies

Sprint Planning (2–8 hours)

Two parts:

1. Identify the Sprint Goal — Product Owner proposes, team refines and commits
2. Plan how to achieve it — Team breaks selected PBIs into individual tasks

Each task is estimated in hours. The team only commits to work it judges achievable.

Example task breakdown for “The player can jump”:

Animator:   Create jumping animations       — 10 hrs
Programmer: Implement jumping control       —  5 hrs
Programmer: Implement jump physics          — 16 hrs
Designer:   Tune jumping                   —  6 hrs

Daily Scrum (15 minutes, strictly timeboxed)

Every day the team meets — standing, in front of the task board — and each member addresses:

1. What did I do yesterday toward the Sprint Goal?
2. What will I do today toward the Sprint Goal?
3. Are there any impediments in my way?

The Daily Scrum is not a status report to a manager. It is the team’s self-coordination mechanism. Impediments are surfaced here but resolved outside the meeting.

Sprint Review (1–4 hours)

The team demonstrates the working game to stakeholders. Stakeholders play it and give feedback. The Product Backlog is updated based on what was learned. The Sprint Review is structured playtesting — see playtesting for complementary technique.

Retrospective (1–2 hours)

Held immediately after the Sprint Review. The team reflects on how they worked together — not what they built. Identifies one or two concrete process improvements for the next sprint. Results are posted visibly and tracked sprint-to-sprint.

Tracking progress

Task board

Columns: To Do | In Progress | Done

Each task card moves across as work progresses. The board makes the Sprint Goal’s status visible at a glance. A “war room” where the team co-locates around the task board is the most effective physical setup.

Burndown chart

A graph of remaining work (hours) against sprint days. An ideal burndown is a straight line from total hours on day 1 to zero on the last day. Common patterns:

• Flat early sections → tasks not being completed or updated
• Steep drop late in sprint → work done but not tracked early; risk of not finishing
• Consistently above ideal line → sprint is in trouble; Scrum Master raises this

Sprint challenges

Sprint interrupted: A sprint may be cancelled if the Sprint Goal becomes obsolete (e.g. major direction change). Only the Product Owner can cancel a sprint. Rare.

Sprint reset: If the team realises mid-sprint that the Sprint Goal cannot be met, they renegotiate scope with the Product Owner — removing lower-priority features to preserve the Goal with a reduced feature set.

Running out of work: If the team finishes early, they pull the next highest-priority item from the backlog with Product Owner input — not arbitrary “nice to have” work.

Sprint without a goal: A sprint with only a task list (no unifying Sprint Goal) loses the team’s ability to make trade-offs under pressure. Every sprint needs a goal statement.

In practice

The “potentially shippable” standard means: playable, no game-breaking bugs, core features for the Sprint Goal are complete. Not necessarily content-complete or final-quality.

For a Unity project over a 2-week sprint:

• Week 1: Feature development; daily builds pushed to shared branch
• Mid-sprint: Internal team playtest to check Sprint Goal progress
• Week 2: Polish, bug-fix, content integration
• End of sprint: Sprint Review build — must run without a developer operating it

Sprint Reviews with real players (even friends or classmates) are more valuable than reviews with studio management alone. See playtesting for how to structure a playtest session.

Evidence

“A Scrum-developed project makes progress in Sprints. These iterations are the heartbeat of the project.” (Keith, Ch. 3)

“Sprints have a fixed duration (timebox) of one to three weeks. Teams commit to working on the PBIs that they forecast they can complete within the Sprint.” (Keith, Ch. 3)

“Think of a potentially shippable version of the game as something you could run an informal focus test with.” (Keith, Ch. 3, Note)

“The Sprint Goal remains unchanged. At the end of the Sprint, the team shows a new version of the game to the stakeholders, which demonstrates the Sprint Goal.” (Keith, Ch. 3)

Implications

• A broken build at the end of a sprint is a process failure, not merely a technical one — the build standard should be maintained throughout the sprint, not bolted on at the end
• The Daily Scrum’s 15-minute timebox is strict; problems raised there are resolved in separate conversations, not in the standup itself
• Skipping the retrospective removes the inspect-and-adapt cycle from the meta-process — teams that never reflect never improve their process

Open questions

• How do sprint lengths interact with milestone deadlines imposed by publishers or university assessment schedules?
• Can student projects run effective Sprint Reviews with classmates as “stakeholders”?
• At what point does a retrospective stop producing useful improvements — and what replaces it?

Related

scrum-in-game-development | product-backlog | user-stories | playtesting | kanban-for-game-dev | overview-agile-game-development | source-agile-game-development | sprint | velocity | definition-of-done