📜 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
Category
Size
Sprint
Status
Assigned to
Notes
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
Designed/Recorded, Implemented
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
Comments