OK. The holidays are over and everyone is getting back to work, so I should to (-_-). My last post was about feature lists and how they can be beneficial to you and your team. Having a list of features that make up your game can help people put things into perspective and organize the development process. You can read more about it in the previous post. Moving on, I’m going to talk about a task list which builds upon the feature list. This portion of documentation is usually what producers and team leads do because it involves coming up with tasks that will be done by the team. I personally think that this is a very important part of game documentation. This is because if your work is very well defined, keeping track of who is doing what becomes a lot easier.
Having said all that, the task list is similar to the feature list, albeit it includes different columns related to the work being done. The key difference between the task list and the feature list is that the task list should show estimates and resource usage. These estimates could be based on what your budget is all about. How you measure your budget or resources is up to you, but generally it is usually done in currency and time. In this case, I’m only going to list time as the cost (although when I go over capacity planning in later posts, I’ll talk more about currency).
The two new key columns I’ve introduced in the task list are the Estimated Hours and Actual Hours. As a producer, project manager or team leader, you need to be able to figure out how long it will take to complete tasks. The reasons for this are many. You want to know how long it’ll take to complete the game. You want to know how much you’re going to be paying your team if they’re pay is based on the number of hours worked. You want to be able to tell if you are going to fall behind schedule and so on. That being said, it is very important to be as accurate as possible when estimating the amount of time it will take to complete tasks. The challenge that comes along with estimation is that you aren’t going to be a subject matter expert on everything (or at least most people aren’t . If you’re a software engineer and you’re trying to do this, you probably won’t have the most accurate estimates on how long it would take to compose musical pieces for your game because it is not your field of expertise. Similarly, if you’re an artist or someone with an art background, you most likely won’t have accurate estimates on how long it will take to build a game engine.
This is where you will have to work with your team to come up with accurate estimates rather than resorting to artificial inflation of the hours (i.e. don’t say it’ll take 20 hours to complete something when it really takes 10 hours). The two columns (estimated hours and actual hours) can help you with this. At the beginning of the project before anyone starts working on tasks, you will have estimated hours for each task. These are based on the estimates you (and hopefully) your team agreed upon. The Actual Hours is the amount of time spent actually working on the given task (to be filled in when the task is complete). Hopefully as your project goes on, you’ll be able to see a trend in accuracy levels (i.e. were you generally accurate or completely off in estimates). This can help you with future project time estimations too.
The next slightly different column is the Resources column. The difference between the Resource column in the feature list and the task list entirely what you want it to be. Generally, you may just want to list the resources as the people (names) who are going to be working on the task or feature. If you want to be super detailed about it, you can also add equipment or tools (such as Maya, Visual Studio, the internet) that are also going to be needed to complete a given task. Doing this will help you manage your resources and help avoid resource usage conflicts.
With all of that said, here’s a simplified example of what a task list could look like (make sure you switch to the task list spreadsheet at the bottom). As mentioned in the previous post about feature lists, this is where the code (or unique ID) that you gave your features becomes important. In this example, the features I’m creating are the Flying Zombie and Shotgun. For the sake of easy reading, I’ve highlighted all the features on the spreadsheet in a light shade of orange (not to be confused with the column headings which are a darker shade of orange), while all the tasks that make up that feature are listed right below the feature. A few things to note about the tasks that make up the feature:
- The estimated Hours for the highlighted feature should equal the sum of all the tasks that make up the feature
- The tasks that make up the feature are prefixed with the same unique ID (code in this case) as the feature, but end with a different suffix or number
- Generally (despite my doing it in this example) you should not have tasks that take more than 8 hours. If you feel something definitely takes longer than 8 hours to complete, you should break it up into more tasks and add detail to it. For example, rather than saying a shotgun takes 17 hours, I broke it down into sub tasks and detailed how long each task will take.
- Some tasks may have dependencies. For example, the person working on the Flying Zombie animations may not be able to complete it until the Flying Zombie Model is complete. In such cases, you need to specify that the task has a dependency. How you do it is up to you, but I recommend simply having a column for dependencies and list the unique ID of the task that the dependent task depends on (hope that made sense)
Hopefully all of this makes sense. I’d like to reiterate that the part of the beauty of this is that you can customize it to what suits your needs. You can add or remove columns that you feel are important to you and your team. The next thing I will talk about is the capacity plan. Check back soon!