How granularly do you schedule your tasks when laying out a project schedule?

Robbie Edwards: This varies depending on the scope, complexity, priority, risk and time available for the task. A complex and high priority task would be scheduled to the day while a shorter, lower risk task would be scheduled just to be completed by. While we would love to schedule every task in units of hours, most tasks, in my opinion, do not warrant that level of scrutiny. I personally feel that game development is so volatile, any efforts to go beyond a “close approximation” are almost futile. Of course, my opinion changes as the project approaches its final weeks and days where detailed scheduling can make a tremendous difference.

Frank Rogan: I like to say that most project management tools are great for projects where all the variables are known ahead of time. If you’re opening yet another branch of Starbucks, you pretty much already know everything you could possibly need to know (construction, permitting, hiring, receiving coffee shipments, etc), and the task is to manage the project against a known model. Game production is no such beast. Design a fight system. How long will that take? There’s no three-ring binder to consult. So, you have to plan around the blue sky development phases.

That being said, the environment changes drastically depending on where you are in the project cycle. The final phases must be planned with far greater detail.

Adrian Crook: Again, since we're using Scrum we map out "user stories" in a prioritized backlog of items that we use to fill up each upcoming sprint. As sprints come up, the granularity of those user stories increases because we know more about them. Really high level user stories - or "epics" as we call them - exist as far into the project as we can map them, but detailed user stories can only exist as we get closer to the sprint they'll belong to.

Peter O'Brien: A couple of rules; basically, anything bigger than 5 days gets broken down. It’s not uncommon to have a 30 day tasks at the beginning of the project if you are not sure what the work entails, but as soon as you understand the demands then the task is broken up into smaller, traceable elements. I don’t like going below a day for a task. Micro management at this level is more of a hindrance than a help … it’s the big brother mentality of development.

If you are evaluating estimates consistently then your schedule should become more accurate as time passes. I'm speaking specifically about code or logic scheduling; content can be a different beast. If you know an object takes 20days to model, there is point in breaking that down. What you might add is texturing time, materials time etc.

Harvard Bonin: I prefer within 2-3 days. That is not to say you aren't aware of tasks that will take 1/4 of a day, but I've never found a need to track people that tightly. Its important to remember that your task list is not the same as your schedule. The schedule is simply used to track team members. The task list tries to take into account all activities, even if they aren't broken out in the time line.