Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Basic Rules For Managing Your Team's Backlog

    [04.14.22]
    - Harry Florencio
  • 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.

Comments

comments powered by Disqus