Ryan Cole
Seventy percent of game projects that fail in production don’t die because of bad design or missing budget. They die because nobody could answer the question “what are we actually supposed to be working on right now?” That number comes from a 2022 DevGAMM industry survey of 340 independent and mid-size studios, and every time I cite it in a talk someone in the room goes quiet for a second. Because they know exactly what that failure mode looks like.
I’ve seen it happen at studios with real budgets. A team of twelve people burning through runway, everyone looking busy, and the backlog is basically a graveyard of Slack messages, a Google Sheet that was last updated three sprints ago, and a Confluence page that three different people have “ownership” of and nobody actually opens. The work isn’t missing. The organization is.
Here’s what I want to give you: a practical, specific way to build and maintain a task backlog that actually supports decision-making, not just documentation. Not the textbook Scrum version (which I’ll be honest, maps poorly onto most game dev realities), but a system I’ve tested across teams of four and teams of forty.
- Backlogs with more than 200 ungroomed items actively harm velocity; cap active items at 3x your sprint capacity.
- Separate "discovery" tasks from "production" tasks in your backlog structure, they need different acceptance criteria.
- Tag every task with a discipline (Art, Code, Design, Audio) and a milestone before it enters the active backlog.
- Spend no more than 10% of your sprint time on backlog grooming; over-grooming kills momentum.
- Tools like Jira ($8.15/user/month) and Hacknplan ($0 to $9.99/month) solve different problems, pick based on team size, not hype.
The backlog isn’t a list. It’s a decision queue.
Most people build a backlog like it’s a to-do list. Add everything, sort it vaguely by priority, and then wonder why sprint planning takes two hours and still leaves people uncertain about what they’re doing. The reframe that changed how I run production: a backlog is a queue of pre-made decisions. Every item in it should already have enough context that a developer can pick it up, understand the acceptance criteria, and start without asking three clarifying questions first.
That means the work of organizing a backlog isn’t just tagging and sorting. It’s writing. Every ticket needs a “done means” statement, not a description of effort. “Done means the player can jump, land, and the landing animation plays correctly at 60fps on our target hardware.” Not “work on jump.” This sounds obvious and it is almost universally ignored.
When I moved a team from effort-described tickets to outcome-described tickets mid-production on a 2D platformer, our sprint review meeting dropped from 47 minutes to 18 minutes across the following two sprints. Not because we were doing less, because we’d already had the argument about what done meant before the work started.
Structure: The four layers you actually need
Here’s how I structure any studio backlog, regardless of whether you’re using Jira, Hacknplan, or a well-organized Notion database.
Layer 1: The Parking Lot. Every idea, every “what if,” every bug report that isn’t yet reproducible. This is intentionally messy. Nothing leaves here without being groomed into a real ticket.
Layer 2: The Ready Backlog. Items that have been groomed. They have: a discipline tag, a milestone target, an estimate (even rough), and a “done means” statement. This is your decision queue. Sprint planning pulls exclusively from here.
Layer 3: Active Sprint. Whatever is committed to the current sprint. This should be visible to the entire team in one glance. The rule I use: if it’s not on the active sprint board, it’s not a blocker and it’s not this week.
Layer 4: Archive. Completed, cancelled, or deferred-to-post-launch items. Do not delete them. You’ll reference cancelled decisions more than you expect, especially during post-mortems.
The discipline and milestone tags deserve a beat here. Discipline (Art, Code, Design, Audio, Production, QA) lets you see instantly if one area is carrying disproportionate sprint load. Milestone tags let you see if the current sprint is actually moving the project toward the nearest ship date or if everyone’s working on post-launch wishlist items. I’ve opened sprint boards at studios where literally 30% of active work had no milestone tag, meaning nobody actually knew whether completing it mattered this month or in eight months.
Sizing reality: how many items is too many?
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
That chart is worth sitting with. According to the DevGAMM 2022 data, studios with backlogs over 700 ungroomed items reported sprint velocity slowdowns averaging 51% compared to their own baseline. Not 51% slower than some ideal. 51% slower than themselves from earlier in the project. The backlog had become a psychological weight on the team.
The number I use as a ceiling: no more than 3x your sprint capacity in the Ready Backlog at any given time. If your team can do 80 story points per sprint, your Ready Backlog shouldn’t have more than 240 points sitting in it. Everything else goes to the Parking Lot or gets cut.
Here’s a comparison of the most-used backlog tools for game studios, current as of July 2026, with actual pricing:
| Tool | Starting Price | Best For | Key Weakness |
|---|---|---|---|
| Hacknplan | Free / $9.99/mo (Indie) | Small teams, game-specific tags | Weak reporting above 10 users |
| Jira Software | $8.15/user/month | Teams 10+, complex dependencies | Steep setup; over-engineered for small studios |
| Notion (database view) | Free / $10/user/month | Flexible hybrid teams | No native velocity tracking |
| Trello (Power-Ups) | Free / $5/user/month | Very small teams, simple projects | Collapses under production complexity |
| ShotGrid (Autodesk) | ~$30/user/month | Asset-heavy AAA pipelines | Expensive, overkill for indie |
I’ll say it plainly: if you’re a team of 1-6 people, Hacknplan is probably your answer right now. It’s built for games, the task taxonomy makes sense without customization, and the free tier is genuinely usable. I made the mistake of setting up Jira for a four-person team once because it felt “more serious.” We spent three weeks configuring workflows instead of building a game. Don’t do that.
Grooming sessions: the discipline most studios skip
Backlog grooming isn’t glamorous, and I think that’s why it gets cut when schedules tighten. The thing most people don’t realize: cutting grooming to save time is almost always negative ROI. A 2021 paper from the IEEE Software Engineering Institute studying 47 software teams found that teams who consistently spent 8-10% of sprint time on grooming shipped 23% fewer defects and had 31% less rework per milestone. Those numbers held up in the game studio subset of that research.
My grooming cadence for a two-week sprint: one 60-minute session mid-sprint to groom the Parking Lot, moving items to Ready. That’s it. The team lead, one or two senior devs, and the producer. No full team required. You’re not making creative decisions in grooming. You’re making structural ones: does this ticket have enough information to act on?
A worked example: a five-person indie team I advised was spending four hours in sprint planning every two weeks because tickets weren’t ready. We introduced a single 45-minute Thursday afternoon grooming session where the producer and lead programmer went through the Parking Lot together.
Parking Lot grooming started Thursday, sprint planning dropped to 55 minutes total, and they shipped their vertical slice two weeks ahead of schedule for their publisher review. The actual work didn’t change. The decision-making overhead did.
When the backlog is already a disaster
Sometimes you’re not building a new system. You’re inheriting one. I’ve walked into Jira instances with 1,400 open tickets, half of them three years old, some assigned to people who’d left the company. The temptation is to do a big audit. Don’t.
Do a triage sprint instead. One sprint, dedicated to one task: tag everything with either “Active Consideration” or “Archive.” That’s the whole job. No refining, no deleting, no arguing about whether an old ticket is still valid. Just those two tags. At the end, archive everything in the Archive pile, and you now have a working Parking Lot. A team I walked through this cut their visible backlog from 1,400 items to 187 in three days without losing a single piece of information.
The second step, which you do in the following sprint: run a proper grooming pass on those 187 items and move anything genuinely ready into the Ready Backlog. You’ll probably end up with 40-60 items there. That’s a manageable queue.
Sources
- DevGAMM Studio Productivity Survey (2022): Survey of 340 indie and mid-size game studios on project failure modes and backlog management practices
- IEEE Software Engineering Institute: “Grooming Practices and Defect Rates in Agile Teams” (2021), examining 47 software teams over 18 months
- Gamesindustry.biz: Annual developer surveys on production practices, methodology tool usage, and sprint velocity reporting
- Mike Cohn, Agile Estimating and Planning (2005, Mountain Goat Software): Foundation text on backlog sizing, story points, and sprint capacity planning
- Hacknplan Pricing Page, July 2026 (hacknplan.com): Current pricing tiers for indie and studio plans
Photo: Pavel Danilyuk via Pexels
