Jordan Lee
Most Jira setups I’ve seen in game studios are basically a software engineering template with “sprint” swapped for “milestone” and a handful of custom fields nobody fills out. That’s not a game dev workflow. That’s a web app workflow wearing a hat.
If you’re setting Jira up for the first time, or you’ve inherited a mess and you’re trying to fix it, you might be wondering where the standard advice goes wrong. Here’s what I tell people: Jira is genuinely good for game dev, but only if you set it up around how games are actually made, not how software products ship. Those are different enough that the defaults will actively hurt you.
Start with your issue type hierarchy, not your board
The first mistake teams make is jumping straight to the board view and starting to drag cards around. Don’t. The board is just a window into your data. If the data structure is wrong, no board layout saves you.
Here’s the hierarchy I use, and have used across projects from a 4-person indie to a 60-person console team:
Epic = a major feature or system. “Player Combat,” “Level 2,” “Audio Pass,” “UI Overhaul.” These map to the things your leads talk about in milestone reviews.
Story = a discrete, shippable unit of work within that feature. “Implement sword swing animation state machine,” “Wire up health bar to player stats.” A story should be completable by one person in a week or less. If it takes three weeks, it’s not a story, it’s an epic you mislabeled.
Task = the smallest tracked unit. Art tasks, bug investigation, a specific document to write. Some teams skip stories and go straight to tasks under epics, which works fine for small teams (under 10 people).
Bug = its own type, always. Never mix bugs into your story backlog. They need separate tracking, separate priority logic, and separate reporting. I’ve seen teams put bugs into the main sprint backlog and wonder why their velocity numbers make no sense. Bugs aren’t velocity work, they’re debt payment.
Sub-tasks are optional. I’d say avoid them until you feel actual pain from not having them, because they add overhead fast.
The fields that actually matter (and the ones to kill)
Jira’s default fields include things like “Fix Version,” “Affects Version,” “Priority” (using a scale from Blocker to Trivial), and a bunch of others that game teams fill in inconsistently and then never use for anything.
Here’s what I’d actually configure:
Discipline label or component. You need to know at a glance whether a ticket is Art, Engineering, Design, Audio, or QA. Jira’s “Components” field handles this well. Set it up. It’ll save you from spending 20 minutes hunting for all the audio tickets before a milestone review.
Milestone or target build. Not sprint. In game dev, sprints are internal delivery cycles, but milestones (Alpha, Beta, Gold, whatever your publisher calls them) are the external commitments. Track both. Use a custom “Milestone” field tied to your release structure. This is how you answer “what’s at risk for Alpha” without rebuilding a spreadsheet every time.
Priority. Keep it simple. I use four levels: Critical (blocking someone right now), High (this milestone), Medium (next milestone or flexible), Low (nice to have). The five-level default scale causes more arguments than it prevents.
Kill the “Story Points” field if your team isn’t doing estimation seriously. Points without calibration are noise. A lot of small game teams are better served by T-shirt sizing (S/M/L/XL) or just tracking days. Don’t cargo-cult scrum practices you don’t have the team size to support.
Board configuration for a game team
Everything You Need To Start Making Games (As A Beginner) · Juniper Dev on YouTube
You probably want two boards, not one.
The first is a sprint board for your active work. This is what your team looks at daily. Columns should reflect your actual workflow states, not the generic “To Do / In Progress / Done.” For a game dev team, something like:
Backlog > Ready > In Progress > In Review / QA > Done
“Ready” means the ticket is groomed, has acceptance criteria, and someone can pick it up without asking questions. That column alone will improve your standups. If something’s been in “In Review” for more than three days, it’s blocked, not in review.
The second board is a milestone or roadmap board. This is what your producers and leads look at weekly. Filter it to show only epics and their status. Jira’s Roadmap view (in next-gen projects) does this reasonably well without much configuration.
Don’t give everyone edit access to both boards. It sounds restrictive, but open-access boards in game studios tend to turn into a game of ticket archaeology within about six weeks.
Automation that’s worth setting up on day one
Jira’s automation rules are underused. Here are three that pay for themselves immediately:
When a bug is marked Critical, auto-assign it to the lead for that component and post to your team’s Slack channel. Takes 10 minutes to set up. Saves you from a Critical bug sitting unnoticed over a weekend.
When all sub-tasks under a story are done, transition the parent story to “In Review.” This sounds minor until you’re managing 40 active stories and trying to figure out what’s actually closeable.
When a sprint ends with open tickets, auto-transition them to the next sprint backlog rather than dumping them into the main backlog black hole. You’ll still want to review them manually, but at least they don’t get lost.
Jira’s built-in automation (under Project Settings > Automation) handles all of this without any external tools or scripting.
The one thing most teams get wrong about Jira and game dev
Sources
- Jorge David Arley Campos
- structure is wrong
Here’s the take that might push back against you: Jira is not great for tracking creative work at the concept stage, and trying to force it to be is where most game teams lose trust in their tooling.
Pre-production doesn’t fit sprints. Concept art direction, narrative exploration, prototype iteration, those things are messy and non-linear. If you put a concept artist’s exploration work into a sprint board, they’ll either game the ticket system or stop using it, and either outcome is bad.
My recommendation is to keep Jira out of pre-production entirely, or create a separate “Sandbox” project with almost no structure, no sprint commitments, and just labels. Use Notion or even a shared Google Doc to track pre-production progress. Once something is in production, meaning the design is locked enough to build against, bring it into Jira. That transition point is the real milestone anyway.
Photo: Jorge David Arley Campos via Pexels
