Priya Sharma
Most Scrum advice was written for software teams shipping accounting dashboards. Game teams are different, and if you’ve ever tried to run a sprint where half the tasks are “make it feel good” or “the combat needs more juice,” you already know the frameworks don’t quite fit out of the box.
I’ve spent years adapting Scrum for game teams, some of them ten-person indie studios, some of them hundred-person AAA departments, and the failure mode is almost always the same: the team copies the textbook process, the sprint board fills up with vague tasks like “polish level 2,” standups become status meetings that nobody wants to attend, and by week three everyone’s quietly ignoring the board. The tool becomes overhead instead of an asset.
Here’s how to actually run a sprint on a game team in a way people will use.
Start with a sprint goal that makes sense for games
The sprint goal is the most underused piece of Scrum. Most teams write it down as a formality and forget about it. On a game team, it’s where the whole sprint either makes sense or falls apart.
A good game sprint goal is a playable state, not a feature checklist. “By the end of this sprint, a playtester can complete the tutorial loop without a producer sitting next to them” is a good goal. “Implement tutorial, add sound effects, fix three bugs” is a to-do list, not a goal.
Why? Games are systems. They break in unexpected ways. If your sprint goal is a list of tasks, the second something takes twice as long as estimated, the whole sprint feels like a failure. If it’s a playable state, the team can make smart tradeoffs: cut the sound effects, ship the playable tutorial, call it a win, carry the sound work forward. That flexibility keeps morale intact across a long production.
On sprint length, I’d push back on the two-week default for most game teams. Early in production, during prototyping or pre-production, one-week sprints give you faster feedback loops on genuine unknowns. Once you’re in production with clearer scope, two weeks usually works. Three weeks feels long and discipline tends to collapse at the end. Pick a cadence and hold it for at least six sprints before changing it.
Sprint planning for a creative team
Here’s what most Scrum guides won’t tell you: game tasks are harder to estimate than software tasks because the creative unknowns are real.
“Build the enemy AI for the grunt” sounds like a two-point task. It’s not. The design doc might be incomplete. The animator hasn’t delivered the attack animation yet. The feel of the attack radius depends on something the gameplay team is still deciding. That’s not poor planning. That’s games.
Flag explicit dependencies on every task. Before sprint planning, your producer or scrum master should run a quick pre-planning pass: identify any task that depends on something not yet finished or decided, and either resolve the blocker before the sprint starts or remove that task from the sprint entirely. Blocked tasks sitting on a board are demoralizing and they’re lying to you about your actual capacity.
For estimation, story points work fine if your team already uses them. If you’re smaller or just getting started, T-shirt sizing (S, M, L, XL) works better for game tasks because it forces the conversation about complexity without false precision. The goal of estimation isn’t accuracy, it’s shared understanding. Does everyone understand what this task involves? That’s the question.
One practical step worth adding: the “definition of done” check. For every task over a certain size, the team should say out loud what done looks like. Not “the player controller is coded” but “the player controller is coded, reviewed, merged, and a designer has tested basic movement in the level editor.” This saves so many arguments at sprint review.
Running daily standups that don’t suck
Jobs in Game Development [Team Management] · Masahiro Sakurai on Creating Games on YouTube
| Tool | Cost Per User/Month | Best For | Setup Overhead |
|---|---|---|---|
| Geekbot | $2.50 | Async standups (Slack integration) | Low |
| Linear | $8 | Game teams, clean sprint boards | Low to Medium |
| Jira | Scales with team size | AAA industry standard | High |
| Notion | Variable | Very small teams | Low |
| Slack thread | Free | Async standups (manual) | Low |
Standups are the most complained-about meeting in any studio. The complaints are usually valid.
The classic three questions work in theory: what did you do, what will you do, what’s blocking you. On a game team of twelve people, they turn into twelve status reports that only the producer needs to hear. Keep standups to fifteen minutes hard. Start a timer visibly. If discussion goes deep, take it outside.
Run standups in front of the sprint board instead of a conference room. Walk the board together. Focus on what’s “in progress” and what’s “in review.” Anything that’s been in the same column for two days gets flagged. This keeps focus on flow instead of individual status, a small shift that makes a big difference.
For remote or hybrid teams, protect async standups. Geekbot (which integrates with Slack at about $2.50 per user per month) or even a simple Slack thread works fine. Async doesn’t mean unaccountable. It means you’re not burning everyone’s most creative morning hours in a meeting.
Sprint review and retrospective: don’t skip these
Sources
Sprint review is where you show the work. On a game team, this should be a play session, not a slide deck or video. Put a controller in someone’s hand, ideally someone who didn’t build the feature, and watch them play what you built this sprint.
You get signal immediately. The designer thought the new ability felt great. Watching fresh hands struggle to understand it tells you something in thirty seconds that a meeting would never surface.
Keep retrospectives short and structured. What went well, what didn’t, what do we try differently. Forty-five minutes maximum. Write down the action items and assign them to a specific person by name. A retro without action items is just venting, which has its place, but it’s not a retro.
For tooling, Linear is excellent for game teams and handles sprint boards cleanly at around $8 per user per month. Jira is the AAA industry standard and pricing scales, but it has more configuration overhead than most indie teams need. Notion can work for very small teams if you’re already living in it. Avoid Trello for anything beyond the earliest prototype phase; it doesn’t scale to real sprint management.
If you’re investing in understanding Scrum more deeply, Mike Cohn’s Succeeding with Agile is still the most practical book on adapting Scrum to real team contexts. For game-specific production thinking, Clinton Keith’s Agile Game Development is the one I recommend most often. Keith has actually worked in game studios, and it shows on every page.
Photo: Ivan S via Pexels
