Basic Rules for Managing your Game Backlog

A game backlog is one of the most powerful tools you can use to give your team focus, clarity, and peace of mind. Focus, because they know exactly what to do next, and even if priorities change, they do so in a structured way. Clarity, because they have all the necessary information for the completion of features, and even if they don’t fully understand the requirements upfront, they have booked time and resources to research and find the answers. And peace of mind, because everything that needs to be included in the game is written down and accounted for in the timeline. The chance of something slipping, if the backlog is properly built and managed, is low. How would your team feel and work if they had more focus, clarity, and peace of mind?

That is the purpose of this article: to help you as a game director or producer guide your team toward this goal.

One appropriate disclaimer: there are several project management tools available in the market. Jira, Trello, Hansoft, HacknPlan, codecks, and others – these last two ones focused on game development. Regardless of your tool of choice, what’s important is that you keep the concepts of good management in mind, and make that happen in whatever environment your team’s in.

First, let’s try and understand what a backlog is, what it serves for, and the main issues we find when managing it.

A backlog is a list of requirements, simply put. It’s a concept coming from the modern understanding of the Agile methodology, and it aims to be a dynamic entity that can easily be discussed, modified, and estimated. It can include new features, feature changes, bug fixes, development tools requirements, and much more. According to the Scrum guide, it should be your Single Source of Truth, or SSOT, the only place where those requirements should exist, and if something is not written in the backlog, it should not be considered for development.

From my experience, the most common issue teams find when managing the product backlog is that, with time, instead of being this helpful and clear list of features and tasks, it becomes a pile of confusing, outdated, poorly-written tickets that the team starts to avoid rather than following. And that doesn’t come as a surprise; game development is such a complex endeavor that, if your tools and methods are too cumbersome to use and understand, the team will avoid them as much as possible, or at least it will require from them a lot of wasted time and effort.

Why does that happen? Mostly for two reasons: either the team leadership didn’t bother to get together with the developers and clearly define the backlog rules in a consistent way, or those rules are too complex and unintuitive. By default, developers want to develop; artists want to make art; designers want to design. It is very rare that the team naturally comes with the ability to use and keep performing with tracking tools in a productive way. And it is your job as a producer to help them, facilitate their work, and improve upon the processes and methods.

Processes should be as simple as you can make them, while at the same time still allowing you to collect the data necessary to make smart decisions and eliminate bottlenecks that harm quality and delivery.

What can we do about it? How can we prevent the backlog from becoming this confusing system and make it a powerful tool for the team?

It all starts by integrating the backlog and design requirements in a smart and productive way. I find particularly brilliant the premise behind HacknPlan: there the documentation, or Game Design Model as they call it, is king. Everything starts there, but even more, everything is connected to the Design Model. A lot of times in game development, the documentation is a separate, parallel process to the development itself; it’s something only the designers and a couple of other folks really dive into. That’s obviously not productive, and it leads to several misalignments between design and development. So the team needs to integrate the documentation and design process directly, not in parallel. In the Design Model hierarchy, if you set it right, you’ll see all progress toward the features right there in the documentation. And this will be your backlog: task management and documentation together in one place.

The most important thing about your backlog is that it should be readable. It should allow your team to gather data and make effective decisions about the features in your game. Remember that your backlog should be your Single Source of Truth – the place where all requirements of the game should exist. That makes it very easy for it to become cluttered and scattered, losing the all-too-important readability. When you continuously skim through it, you should find everything that’s related to your game, in a high-level format, and then be able to go down on the levels of detail as required.

That’s why the Design Model makes sense; in this Model, you will list and detail the mechanics, systems, and assets that your game possesses in their entirety. It basically comes from the Game Design Macro Chart – a sheet that lists all of the related systems and assets that you plan to have in the game. You structure your backlog in such a way that your hierarchy gives you the ability to read it in many different layers, thus giving you different levels of information.

On the top layer, the team will be able to understand the entire scope of the project, with all assets and systems plainly visible. At the mid-level, you can quickly visualize the scope for a specific feature or milestone and will be able to estimate it and understand its dependencies with other features. And by looking at the low-level, granular tasks, the developers can focus on what needs to be done right now, and how to build it.

This structure is key; the game director, lead designer, and lead producer need the ability to easily switch from a high-level overview to the details of the daily assignments. So, regardless of the tools your team is using, always think about backlog hierarchy and the ability to manage levels of detail.

Okay, this makes sense to you, hopefully. You can go there at the beginning of the production phase and build your backlog for the win. But how do you maintain it like that midway through development? How do you keep it clean when bugs start pouring up? Well, for one thing, keep the readability of your backlog with different levels of hierarchy. But also, keep your rules simple. But wait, what rules?

Backlog rules are the instructions that your team applies when using the backlog. They are the answers to the following questions: when do we create new tickets versus update the ones we already have? Do we include them directly inside the sprint, on top of the backlog, or maybe at the bottom? If someone identified a missing feature or system, how is it created and assigned? If a system overlaps two or more different features, where should it be included in the Design Model/documentation? How much do we break a feature down in the backlog, and when should that happen?

All of these questions define how you and your team work with the backlog on a daily and weekly basis, and also it clarifies the understanding of the team about tasks and features. Always keep in mind that readability is king. When you review the high-level layer, you should be able to read it without concerning with the details; and when developers read the granular information of a system or task, they should have all information they need to complete it. To achieve that, you must keep your backlog rules simple, so your team can understand and follow through without getting bogged down on how to apply them.

Try to have no more than ten major rules that you and your team have to follow, and keep them as intuitive as possible, always starting from the readability with layers of hierarchy. You and your team will create the master rules that better suit your needs, but here are some general ones that can be used as a starting point:

THE BACKLOG IS ORDERED FROM TOP TO BOTTOM

Extend the intuitiveness that you have from the backlog as much as you can, and a simple way to do that is to order features from top to bottom, the top ones being the next thing you intend to include in the sprint or milestone. So tickets are grabbed in that order. You can, additionally, choose to plan a couple of sprints ahead – usually, no more than 2 or 3, or your predictions start to be less and less accurate. The top of the backlog will then be the next features and tasks that you are considering doing after the planned sprints.

BUG REPORT SHOULD NOT HARM READABILITY

You can either use a separate backlog for bug tracking purposes, or have them in the same backlog, but creating filters that allow you to quickly toggle bug tickets on and off. You want to have the backlog as your SSOT, so it makes sense to keep everything in one place, but a pile of bug tickets can simply harm the readability too much and hence not be efficient to use.

ORGANIZE HIERARCHY IN LEVELS OF DETAIL

As one of the primary takeaways from this article, you should use your tracking tool in order to allow for easy hierarchy access, so that you can read high-level features and the overall scope of the game, versus reading through detailed requirements and updates per task. If you are using Jira or other tools with similar Agile concepts, this higher level will usually be composed of the Epics, and you will use them to create the roadmap of features. Other systems may have different concepts; just keep in mind to have strategic levels of organization and detail.

CHECK TEAM VELOCITY AGAINST SCOPE

This is one of the simplest ways that you can analyze if your project is on track or not. What you need is to have at least a couple of sprints completed (or any other timeboxed technique if you’re not using sprints) so that you can check the velocity of your team – how much work they can get done consistently. While additionally having the backlog features and tasks estimated, at least to a reasonable level of precision. With that, you can easily create a schedule comparing how much work is left versus how much the team can complete in a given amount of time. From there, in case you’re not hitting the deadline and requirements, you can add more resources, extend the timeline, reduce scope, or maybe improve some processes and tools to make the team more productive.

HAVE WEEKLY BACKLOG REFINEMENT SESSIONS

Gather the game director, lead producer, and team leads to conduct backlog refinement, which means constantly adding or removing features and requirements, extending estimations and descriptions, and overall updating priorities and information regarding the features. Your team will not, ever, have the full understanding of all game requirements from the get-go. This needs to be improved and extended throughout the project. That’s where backlog refinement comes in, and it helps the team to always build more knowledge about the project. Plus, it helps to tackle obsolete requirements faster, instead of having dozens of outdated tickets pile up in your list.

DON’T BREAK EVERYTHING DOWN UPFRONT

Don’t try and break down all features into individual tasks during preproduction, because your estimations will most likely be wrong. The team’s understanding of features will evolve over time – that’s the point about backlog refinement. You can break the major features down into smaller chunks that you know are coming and estimate them – an Inventory system probably needs a drag-and-drop feature and equipment slots.

But what if the designers decide to create a more immersive Inventory with minimal UI? Keep the breakdown high level enough if you are not implementing the system in the next few sprints. Naturally, the best phase to have the design fluctuate like that is in preproduction; by the end of it, after the Vertical Slice, it’s increasingly dangerous to change big design aspects of your game. So, during production it becomes safer to break everything down and estimate it – taking the systems and assets from your Game Design Macro Chart.

MANAGE MILESTONES AND RELEASES

The Game Design Model, as well as the Macro Chart, will list and describe features, systems, and assets in your game so that you have a full (even though evolving) understanding of the scope. However, the Design Model lists features as a whole, in a linear fashion, while releases will make your game evolve as a playable entity, so you and your team can assess the experience being designed. Game development is an iterative piece of art, and your prototypes will not be linearly constructed. During preproduction, while creating the Vertical Slice, you will likely build things concentrically, polishing levels and systems as you go, so you can validate that fraction of the experience with high level of quality. In contrast, during Alpha, your goal might be to create every missing system and type of asset in a rough state so your game can be feature complete. These different types of milestones can be more easily managed separately via releases while not affecting the integrity of your backlog.

Within the backlog, you see the full scope in distinct levels of hierarchy; in the sprints, your team concerns with the actual work to be performed and generate new playable builds to be reviewed; and via releases, you manage how you construct and validate your game in the timeline. This process will grant you powerful control over the different types of scope in your project.

Managing a game backlog, just like game development itself, is an art. It involves systems, and logic, and good sequencing, but it also involves people, and thorough communication, and the ability to respond to changes. You may read articles and books and take classes about it, but it all comes down to practice and experience. Each project is different, each type of game, and each team will respond in a different way. Your job is not to force your people to do something they don’t want to because management requires it; your job is to empower them with tools and techniques so they can achieve more satisfaction with the work, and a better game at the end.

Keep one last rule very close to your heart: if something doesn’t benefit your team and the quality of what you’re making, get rid of it.