After completing my three part series “Designing A Production Process” over two years ago, I’ve since felt that it could be helpful to go a bit deeper on setting up your task/bug database to support this process in a few key areas. It’s a very practical way to start turning something hypothetical into a tangible reality. So, before moving on I definitely suggest reading the original series, but I don’t think it’s necessary.

Database of Choice

Most game devs I speak to today are using JIRA to track their tasks and bugs. JIRA definitely gets the job done, but man is the administration of that database a pain in the ass. First of all…the interface. It’s super confusing to navigate the admin pages. And related to this first point, there’s too much crap packed into JIRA, making it extremely difficult to find the features that are actually useful. “Discoverability” is not a thing. I think the best immediate improvements to JIRA would be stripping it down to an “essentials only” version.

That said, my suggestion for you is to avoid JIRA and opt for something like YouTrack. I think the best way to describe YouTrack is JIRA-lite…which is perfect, cause JIRA is way too dang heavy. I find it has everything I need and almost everything I want. Not to mention, there’s a free version for us small indies! JIRA is actually one of the few ubiquitous pieces of software used for game development that doesn’t have a free version for small teams :/

The screenshots I’ll be referencing below are from YouTrack, but they should apply directly to JIRA since there’s always going to be an equivalent there (and most other issue tracking databases, as well).

Issue Fields

Here’s a complete list of all the field types I currently need to track issues for my project that expands upon Part 2 of the original series. I may add a couple more as the project progresses/demands, but I think this is a good baseline and you should seriously consider culling fields you’re not utilizing. It’s that much more of a pain in the ass to create a new issue if you have to navigate through a bunch of unused fields. Nobody likes spending time in an issue tracking database, so it’s your job to ensure the experience is as frictionless as possible.

Note that I’ve specifically highlighted the “Feature” field and the naming convention for defining new features: “[PARENT FEATURE] Sub Feature” (in JIRA, you might just want to use a cascading select list). Some Sub Features have a ‘.’ prefixing them. This denotes a Sub Feature as a “supporting feature”. As an example, “[AI] .Perception” is a supporting feature that all AI units utilize. However, “[AI] Seeker” is a proper AI unit and is therefore not a supporting feature for the parent feature. If you sort alphabetically, the supporting features will rise to the top and instances follow after that. I find this convention to really help with organization...and if you think maintaining an issue database is anything BUT an exercise in being organized, you’re wrong ;P

This naming convention also feeds into my template when writing up the “Summary” for a new issue. They all follow this pattern: “[PARENT FEATURE] Sub Feature - Summary of issue”:

[AI] Seeker - Increase the weapon fire rate
[ENGINE] Optimization - Evaluate framerate spikes
[HUD] Health Bar - Make it blink when health is low

I like this convention for the Summary because although the Parent Feature and Sub Feature are set in other fields, having them represented in the Summary ensures there’s always going to be a baseline level of detail when creating reports on the database. It’s very common that reports only reference the Summary field and nothing else.

Agile Board

See below for the lanes I display in my Agile Board. This will look familiar if you read through Part One of the original series. You’ll notice I’m not totally eating my own dog food by assigning time estimates to all these tasks. I’m the only developer on this particular project and it doesn’t have a proper release timeline yet, so…I should probably be more disciplined, but that’s my bad excuse. Make sure you add estimates if you actually have a team w/ deadlines!

My Dashboard

I spend most of my time planning projects by evaluating a series of dashboards that are organized by “Feature” and one special dashboard that is tailored for the current user called “My Dashboard”. I’ll start with this special one that should be the first browser tab everyone opens when they begin work for the day.

“My Dashboard” summarizes all open issues in the database that are assigned to you. Widgets in the left column are some interesting ways I like to slice the data. If you’re familiar with Part 3 of this original series, you’ll note that the idea of displaying “Current Sprint”, “Next Sprint” and “Future Sprints” falls in line with laying down 3 sets of train tracks before you hit the “Contained Chaos” (e.g. The Backlog).

Dashboards are the one area where YouTrack falls short of what I want…but they do provide everything I need. Specifically, you can’t customize the fields displayed in the issue lists and you can’t dynamically sort the list with a simple click of the column header. JIRA does this and it’s way nicer evaluating the dashboards in this way. They also allow for some custom coloring of widgets. These are some nice features, but don’t break my workflow in YouTrack and the simplified experience overall is worth missing out on them.

Feature Dashboards

These are organized much like My Dashboard, but the “Backlog” portion is broken down per sub feature. Every single parent feature has its own dashboard. Here’s an example of one in my project.

Sprint Planning

The last thing I’d like to call out is the “Estimation Report” in YouTrack. It’s crazy useful for evaluating how packed someone’s schedule is for a given sprint and is exactly what you should be reviewing in the “Schedule Resolution Meeting“ described in Part 1 of this series. Here’s where you create one in YouTrack:

Here’s what they actually look like. Remember, this project is just me but it will display your entire team with the right filter.

THE Endendum

If you can utilize YouTrack in the ways I’ve described above, you’re gonna have a pretty great toolset for implementing a pro level production process! Hope this addendum helps your project just a little bit more :)

Designing A Production Process: An Addendum