Priya Sharma
Most sprint planning guides are written for software teams building CRMs. They assume you have a scrum master, a product owner, a development team, and a QA department. If you’re a four-person indie studio where the “art director” also does UI and occasionally writes dialogue, that framework is going to fit you like a suit two sizes too big.
Here’s what actually works when your whole team fits in a Discord call.
The Sprint Length Question Nobody Agrees On
| Sprint Length | Best For | Overhead | Duration |
|---|---|---|---|
| One week | Full crunch/polish mode near ship date | High | Tight daily visibility |
| Two weeks | Software with stable requirements | Medium | Industry default |
| Three weeks | Small teams (under 6) making full games | Low-Medium | Sweet spot for discovery & iteration |
Two weeks is the industry default and it’s usually wrong for small game teams. I’ll defend that.
Two-week sprints were designed for software products where requirements are relatively stable and you’re shipping incremental features to live users. Game development is different in a specific, important way: your tasks have wildly different uncertainty profiles. “Implement jump mechanic” and “figure out why the jump feels bad” are both sprint tasks, but one is estimable and one is a discovery exercise. Two weeks doesn’t give you enough time to discover, iterate, and close the loop.
Three-week sprints are the sweet spot for teams under six people making a full game. You get enough runway to actually finish mid-complexity features, the rhythm isn’t so long that things go sideways without anyone noticing, and you still have a defined moment of accountability every few weeks. I’ve run both, and three-week sprints consistently produced better outcomes on smaller projects.
One-week sprints are only appropriate if you’re in full crunch polish mode, close to a specific ship date, and you need tight daily visibility on what’s burning. Otherwise they generate more overhead than value.
What to Actually Do in the Planning Session
A lot of small teams skip formal sprint planning because it “feels like corporate process.” What they do instead is a loose Monday conversation that produces no clear commitments and dissolves into everyone just doing what seems important. Six weeks later, half the game is unfinished and one person has been polishing the main menu for three weeks because nobody said otherwise.
Sprint planning doesn’t have to be long. For a team of four, ninety minutes is plenty. Here’s the sequence that works:
Start with a brief review of the backlog. Fifteen minutes, maximum. The producer (or whoever owns scope) walks through what’s prioritized and why. No deep debates here. If something’s genuinely contested, park it and discuss after the session.
Then estimate together. Use story points or T-shirt sizing, not hours. Hours are fake for creative work. When I was at a mid-size studio we estimated in hours for two years and were wrong by 40-60% every sprint. Story points force you to think in relative complexity, which is actually what you’re uncertain about. A “5” means “this is about twice as hard as a 2 and half as hard as a 10,” and that’s enough.
Each person pulls tasks until they’re at capacity. Don’t overfill. If your historical velocity is 30 points per sprint per person, don’t plan 45 because “we’ll push.” You won’t. You’ll carry over half your sprint, demoralize the team, and learn nothing about how to improve.
Write a sprint goal. One sentence. “By end of sprint, a player can complete the first level with functional enemies and collectibles.” If you can’t write it in one sentence, your sprint is probably trying to do too many unconnected things.
Handling the Specific Chaos of Game Development
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
Game dev breaks sprint planning in ways that pure software dev doesn’t, and most guides don’t acknowledge this honestly.
Art tasks are almost impossible to estimate accurately. A character model might take two days or eight depending on feedback loops, reference quality, and how many times the art direction shifts. The practical fix: give art tasks a time-box instead of a point estimate. “Four days on the hero character, ship whatever state it’s in.” This forces a conversation about what “done” means upfront rather than at the end.
Game feel work is even harder. “Make the combat feel punchy” is not a sprint task. Break it down: “Add hitstop on enemy hit (0.1 seconds),” “Add screen shake on heavy attack,” “Review and tune particle counts on hit effects.” Each of those is estimable. The vague version isn’t.
Bugs are going to eat your sprint capacity whether you plan for them or not. Reserve 20% of sprint capacity explicitly for bug triage and unplanned work. Write it into the sprint as a line item. If you don’t use it, you finish early and bank goodwill. If you don’t reserve it and bugs hit anyway, your sprint explodes and everyone gets frustrated.
External dependencies are the quiet killer. Voice recording, licensed music, an outsource artist delivering assets: if any sprint task depends on someone outside the team, flag it explicitly and have a contingency task ready to swap in. I’ve seen two-person teams lose an entire sprint because they were waiting on an external contractor and had nothing else ready to pull.
Tools Worth Actually Using
Sources
For backlog management and sprint tracking, Jira is the obvious choice and it’s probably overkill for a team under eight people. The free tier of Linear is genuinely excellent for small teams and the interface doesn’t make you want to quit gamedev. Notion works if your team already lives in it, but you’ll build your own sprint board from scratch which takes time you probably don’t have.
For estimation sessions, PlanningPoker.live is free, runs in a browser, and takes five minutes to set up. No install required. It removes the social pressure of estimation where the junior dev always agrees with the senior dev’s number.
If you want to go deeper on the theory, “Agile Game Development with Scrum” by Clinton Keith is the only book I know that actually addresses game dev specifically rather than just transplanting software agile wholesale. Some of it is dated now but the core frameworks hold up. Pair it with the GDC Vault talks on production (many are free) and you’ll get a more complete picture than most online courses offer.
For tracking velocity and generating simple burndown charts without a lot of setup overhead, Shortcut (formerly Clubhouse) has a clean sprint view that works well at small team scale.
Photo: Diva Plavalaguna via Pexels
