Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 22, 2014
arrowPress Releases
October 22, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
The devil is the details
by Samuel Rantaeskola on 01/11/13 08:14:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 
Devil 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.


Related Jobs

Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States
[10.22.14]

Producer
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[10.22.14]

Art Director
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.22.14]

Senior Game Designer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.22.14]

Producer - Infinity Ward






Comments


Eric Smith
profile image
How do you typically track time estimates on a project that can span years, if the backlog isn't granular? Or if you need to cut scope within specific features?

Samuel Rantaeskola
profile image
Let's assume that you plan a project into a high level of detail a year or two forward. The likelihood you will execute on those small goals a year from now is pretty low. Things change, new ideas pops up and reviews of current features opens new roads. Spending time on a granular breakdown of the backlog will give you a false sense of security.

Given that the top of the backlog are the most important things in the game, that's where you should spend your time and make it granular. The further down on priority the more nice-to-have it is, meaning that it's highly likely that a number of those features will not be done at all, so why spend time on them until it becomes likely that you will be able to tackle them.

When it comes to scope control, I'm talking about the high-level scope not the details. Questions like, "It looks like we only will be able to make 12 weapons in this game with only one year left. Which three of our 15 should be cut?" is meaningful. Whereas this one is probably not as good "Can we remove the animation from the shotgun, muzzle flare from the mini-gun, etc to be able to complete all the weapons?". The latter will consume insane amounts of time to make good decisions, too much info available.

On the point of estimates, we like to think that breaking things down means that we get a better idea of the scope of the feature. My view is that it's the totally opposite, we loose information as we break down items. We tend to loose all the work needed to make the components work together. A rough estimate of the size of high level goal is often enough to give an idea of how big it is compared to some other goal.

Estimation and prioritization in the backlog is a really difficult topic, and there are a lot of room of improvement in the games industry within that area. We tend to want too detail games too much too early. This leads to bad scope control and decision making, which in the end leads to hectic end phases.


none
 
Comment: