Backlog Management

📜 See all articles: Sitemap

⬅️ Previous Article: Estimating

➡️ Next Article: Sprint Planning

As you build your game, you’ll need to keep track of a to-do list of tasks and features that will make your game complete. Enter the backlog.

The backlog is your game’s to-do list, and it’s filled with all the agenda items that you’ll populate a sprint with. Established studios use programs like Jira (far and away the industry standard), Azure DevOps, or similar project management tools for their backlogs. You probably don’t need to get too heavyweight. Notion is a great tool, as it offers a relational database (change a field in one place, and it'll update a field somewhere else) without being cumbersome.

All the examples here are Google Sheets. Google Sheets will do. I've used Google Docs and Sheets to create templates for this website (they're convenient and widely used), but I use Notion if I have a serious project to tackle.

Let’s take a look at a very simple example: Sample Backlog. One note: this backlog contains a small fraction of the work items you’ll need to create your game. Yours will be more unruly and complex.

Sheet 1: The Sprint Schedule

While not essential, it’s helpful to capture the dates of your upcoming sprints. I like to have a vague plan looking at least one sprint in the future, but ideally you’ll have a decent idea what you’ll be working on a few sprints out.

Let’s say it’s August 1st, and by the end of September you want to have eaten a whole elephant. Now I know the adage is “bite-by-bite,” but just having a few bites each day gives you little sense of whether you’re on track. Since you know you need to eat the whole elephant by the end of September, you can probably surmise that you’ll need to eat at least one leg by August 15th, and two legs by August 28th. That’s the type of progress we’re talking about tracking here.

I’m usually working with milestones, so I update this sheet to include the sprints affiliated with our current milestone. For more info on milestones, see Milestones.

Sheet 2: Coding Backlog

This is the main sheet to review, and by itself, it’s enough to constitute your backlog. Let’s go through the columns (note--there's a lot of good content under "Description," so make sure you don't miss it):

Date Added

Example: 08/04/2024

Why track it? Old tasks that don't get prioritized should often get tossed.

Date's important so you know how long something’s been hanging out on the backlog. Long-standing tickets that never get prioritized are often bloat: items that seemed like good ideas at the time but aren't important enough to develop.

Backlogs always fill up with bloat. Why? Because someone has a bright idea for a new feature, and it’s “essential,” and so it gets added to the backlog. But it’s never quite essential enough, or a better idea comes around, and so it never gets prioritized.

That's why backlog grooming is important. Grooming is the process of running through the backlog and prioritizing, deprioritizing, and deleting tasks. It’s essential for keeping the team focused on the right tasks, and for making the backlog more approachable.

I typically advise grooming on an as-needed basis. If you feel physical pain looking at your backlog, it’s probably time to groom.

Description

Example: "Add AI pathing to helicopter dog"

Why track it? Every task needs a title. Some need a whole page.

I use the "Description" field to title a task. It should be detailed enough for the assignee to understand what they're working on, but simple enough to reference it in conversation. If I have more detail to add to the task, I'll use the “Notes” column to add a sentence or two. And, if the task merits it, I'll link a separate requirements document to the description.

Scrum tasks mandate user stories and acceptance criteria, so I want to talk about each of them and their use cases.

• User stories are the archetypal way to define software development features. They go something like this: “as an administrator, I want to be able to control access to other users’ web traffic.” They then answer key questions: how should limiting work?; what levers should the administrator pull?; etc. This all gets rolled up into acceptance criteria.

  
  

• Acceptance criteria is what you check against to determine if a feature is done and meets expectations. It's helpful for providing clarity and guidance, especially if the person who generated the task isn’t the one working on it.

I never write user stories for video game features. They're kind of weird: consider “as an enemy’s pistol, I want to have two modes of fire.” Acceptance criteria is a lot more useful. For small tasks, I can capture acceptance criteria in "Notes," but for large features, and when working with contractors, I need more detail.

When to Link to a Separate Page

Contractors

If you’re working with a contractor, they probably don’t have access to your backlog or Discord server. It’s a much more transactional relationship, with limited opportunities for revision. This is a situation where hyper-specificity will save you a lot of time. I recommend providing a detailed request of what you’re looking for, complete with examples from other games where possible.

Large Tasks

If you’re working on a larger task, say an 8 or 13 (See: Estimating), it’s valuable to create a separate space to jot down information about that task. 8s and 13s are complex, and there’s a lot of decision making that will go into their design.

On the sample backlog, you can see a 13 finished in sprint 1 titled “Improve enemy engagement behavior.” Were it a real task, I’d link that to a separate requirements document that would outline what improving enemy engagement behavior looks like. That doc could detail the way that I want each enemy to engage with the player, including diagrams and pseudocode that help visualize the desired changes.

“Improve enemy engagement behavior” asks for extra documentation not just because it’s large, but because it’s vague. You can imagine that it was added as the result of a specific complaint. It may even have been added as the result of a focused playtest (see: Continuous Playtesting). Be sure to capture those complaints in your documentation, or at least link to a playtest writeup that documents complaints and suggestions.

Requirements documentation serves another beneficial role: making it easier to create Game Design Documentation. If you’re building a new system, chances are you’ll be able to transfer a lot from a requirements doc over to a game design article.

Category

Example: Art, UI, Engineering

Why track it? At a glance, see who's got a lot going on.

This optional column allows you to categorize the items on your backlog. It’s useful if you intend to combine multiple disciplines on one backlog—such as Art, UI, and Coding. It can also be used to organize tasks by category—for example, to relate a task to the player character vs. a crafting system.

I generally shy away from Categorization where coding is concerned. I prefer to have disciplines siloed on separate backlogs. It makes it easier to visualize the path for each discipline. I’ll get more into categorization on Art and Sound backlogs below.

Size

Example: 1, 2, 3, 5, 8, 13

Why track it? It's essential for sprint planning.

The size you’ve estimated a task at. This can be left blank when you initially add an item. For more detail on sizing, see Estimating.

Sprint

Example: Sprint 3

Why track it? Use it to earmark tasks for the next sprint, and to be able to look back at work from past sprints.

The sprint you’ve assigned a task to. I’ll sometimes speculatively assign items to sprints that haven’t happened yet. It’s a good way to provide the team some vision on what’s to come.

Status

Example: In Progress, Complete

Why track it? It's useful when reviewing the results of the last sprint.

Typically used as a way for people to let the team know when they’ve started or finished a task. It’s visually helpful at the end of sprints as an indicator of progress. It costs nothing to include it and requires little work to maintain—just make sure it’s updated before your end-of-sprint meeting.

Assigned to

Example: John, Sally

Why track it? Everyone should know who's responsible for each task.

This is pretty self-explanatory. At larger studios, you could assign tasks out to scrum teams, but with a smaller studio, you’ll be assigning them out to individuals.

Notes

Example: - HUD should flicker when health < 30%; - See style guide for font choices (here)

Why track it? Not everything fits neatly into the other columns. Notes are an easy way to add detail without needing to navigate to a different document or tab.

The notes column is used to add more detail (1-2 sentences) to smaller tasks. You could also use this column to note blockers.

Blockers are prerequisites to tasks. An easy, colloquial example: you can’t move your car before you find your keys, so “find your keys” is a blocker to “move your car.”

It’s helpful for both you and the team to know when blockers exist, especially when their removal is another team member’s responsibility. If sound is waiting on UI to implement a menu so that they can integrate their sound effects, UI knows to implement that menu ASAP before turning to other, more isolated sprint tasks.

Depending on how essential it is for you to keep track of blockers, you might choose to grant them their own column. On a small team, that can get cumbersome. Task management systems like Jira have built-in functionality to manage blocker assignment, simplifying the management a little, but standing up and organizing Jira is its own burden. For small teams, I think open communication is a sufficient replacement. Your mileage may vary.

Sheet 3: Sound Backlog

When it comes to sound and art, I think it’s much easier to scope out work early. I’ve created a separate sound backlog to showcase an alternate organization system for these disciplines. It’s still a to-do list, just in a different shape.

The key difference, and the prerequisite to organizing your backlog this way, is that you'll need to do more upfront scoping and planning. Imagine you’re designing a racing game that takes you through the streets of your hometown. You’ll probably end up with a lot of tweaking when it comes to gameplay mechanics—making sure the handling is smooth, handling scoring, handling collisions, etc. There are definitely cascading tasks here.

But from an art and sound perspective, there are many definite knowns. An artist will need to design the arena, a certain number of cars, the track, grass, a skybox, fans, etc. The sound designer will need to design menu sounds, the throttle, the sound of tires screeching, fans cheering, etc. It’s an easier list to build, so it’s not as much of a problem to do the work up front.

That’s not to say you can always come up with an exhaustive content list on day one. As design changes, so do art and sound requirements. But it’s easier to start with a deep bench of work when it comes to art and sound.

Let’s take a look at the new fields.

Category

Example: Player, Enemy, Environment

Why track it? It's the best way to organize work on a single-discipline, content-driven backlog.

On the Coding backlog, we used Category to refer to the discipline completing the work, such as "UI" or "Design." Here, we're using Category to refer to the section of the game that work corresponds to. For example:

• If you're working on the player model, use "Player."

• If you're working on the sound of an ion cannon reloading, use "Weapon."

I think categorization adds quite a lot in this format. It’s both a tool to organize your backlog and a means to generate more ideas. If you can split your game into components—for a racecar game, you might pick categories like “Car,” “Announcements,” “Environment,” “Menu”—you can more easily think of needs for each category.

Sound Name

Example: ioncannon_reload.wav

Why track it? Your backlog now doubles as a cheat sheet for file organization.

Sound name isn’t essential—you could instead use a plain description. I just included it to show an alternate organization system. When I’ve done sound design in the past, I use these file names in lieu of description just to have a dictionary when I’m parsing through a folder of sound files.

Designed/Recorded, Implemented

Example: Yes/No

Why track it? Many sound/art tasks have multiple steps. Columns like this help you organize them without adding rows.

Art and sound have enough repetitive workflow that you can create compound tasks on their backlogs. A compound task has multiple steps that can be easily split up and visualized.

In this case, I’ve split sound design and implementation up. They’re quite different tasks, using different parts of a sound designer’s toolkit. A sound designer may find it more efficient to do a bunch of design work, then implement everything. If you’re using voice actors, you’ll almost definitely do recording in batch before you tackle implementation.

There’s two disadvantages to compound tasks:

1. If you have one person handling design and another handling implementation, then you have one task assigned to two people.

2. Since each task just has one size, it’s hard to know how much work remains when Design is done but Implementation isn’t.

I consider the first to be a dealbreaker for compound tasks. I really want each team member to have a clear backlog for their work. If I had a coder handling implementation, I wouldn’t setup a backlog with compound tasks.

I don’t consider the second to be a dealbreaker, and I’ll usually use this format if there’s just one person involved in SFX. I think it’s easier for them to manage, and it feels clean. As always, use the system that works for you.

Sheet 4: Bugs

You can run a bug tracker as a separate tab on your backlog sheet, or you can make a brand new tracker for bugs. I like to combine them so that all outstanding work fits in the same file.

Most of the columns here are either self-explanatory or covered earlier. The one I want to draw your attention to is "Steps to replicate."

Steps to Replicate

Example: 1) walk over to the door, 2) press "X" while facing the lightswitch

Why track it? It saves people time when they're trying to figure out how to replicate a bug that you logged.

You know how I downplayed the importance of documentation for small tasks? That doesn't apply with bugs. Bugs are well-named nuisances that reach full headache potential when you can't replicate them.

Whoever submits a bug is responsible for sharing how they discovered it in the first place. While this won't always make replication easy, it creates a good starting point for the engineer tasked with squashing it.

I recommend maximum detail when you're creating a bug report. For example, the second bug might have nothing to do with the armor that Commander Shepard was wearing--or the armor could be the cause of the bug. It's helpful for the assignee to know the player's exact state when they first experienced the bug.

In conclusion

Established studios would shudder at depth of detail I’ve omitted in these simple backlogs. For small, communicative teams, they work. They’re sufficient to keep the team organized without subjecting you to clerical hell.

For a long-term project, I’d probably implement a tool like Jira simply for recording keeping. I still advocate for Notion over Google Sheets. It's best to get used to something with a bit more power. For now, though, if you've got something very simple, Google Sheets will do.

Now that you're familiar with Estimating and Backlog Management, we can get deeper into the weeds of Sprint Planning.

📜 See all articles: Sitemap