Back after the holidays I was contemplating what topic to choose for my first blog in 2013. Looking back at the 2012, most of my time was spent on backlog management. With that in mind a logical start for 2013 would be to discuss my learning within this area. I’ve seen a large number of game backlogs during the year and it’s safe to say that the biggest impediment is the level of detail that goes into the backlogs. It’s not uncommon to see, for example, whole animation sets broken down into individual animations. This can easily sum up to tens of thousands of items alone.  I assume that the reasoning behind this is that it feels like the control of the scope is increased by adding more details. In reality it makes it hard to see the forest for the trees.

The side effect of adding massive amounts of details to the backlog is that prioritization becomes impossible. How do you prioritize “run turn left 90 degrees” versus “shotgun muzzle flare”? 

Ideally the backlog should represent the vision of the game, not the list of tasks needed to build the vision. If a player read through the backlog they should ideally feel excited by all the cool stuff you’re going to put in the game. Essentially you want your game design to be reflected in the backlog, not how to get there. In an earlier post I linked to this video that is a speech I gave on this topic. 

There are plenty of books written about backlog management, and I’m not going to go on forever about this. To be concise, here are my 3 main arguments to why you should refrain from going into too much detail in the backlog: 

1. Goals are important, tasks are not.

When your backlog is an endless list of tasks the making of the game can easily become a death march of just completing tasks. You lose the ability to celebrate the completion of milestone components in the game.   

2. Better decision basis

With a “short” list of high level goals it is easier to overview the status and the game and make decisions of scope or prioritization changes. 

3. Better scope control 

It’s easy to get fooled that by details. It feels like you have a very good control of the amount work required to finish the game. However, in breaking items you usually lose some of the glue, the things that you actually need to do to make all the components work together. In reality the sum of the work in the individual tasks doesn’t add up to the total time it takes to complete the goal. I would argue that estimating how big effort is required to build, for example, a particle system will be a better approximation than listing each individual task and summing up the time for them. Given that you don’t confuse time with effort in the backlog. 

I have no doubt that 2013 will hold a lot of backlog discussions as well as I see it as one of the key elements to successful game productions.