Being a composer of video game music can be a tough gig.  If you’re working for a smaller studio or indie developer, it’s often made tougher by added responsibilities like audio direction, directing and recording voice actors, sound design, and implementation (to name a few).  With all of those moving pieces and assets that need to be created amidst an organic game development process, you can easily find yourself mismanaging your time.  And remember – your time is your money!  Nobody likes working with a freelancer who is all over the place and takes too long to complete the tasks at hand.

 

Luckily for us all, we have help: Ryan Davies.  Ryan reached out to me awhile back with this AMAZING article that YOU SHOULD READ AND SHARE WITH ANYONE IN THE GAME INDUSTRY THAT YOU CARE ABOUT.  In this post, Ryan teaches us how to apply Agile – a project management system – to a game audio project.  Agile is one of the most popular workflows for large project management (especially in software), so read and be enlightened.  You don’t have to commit completely to the Agile system to learn a thing or two that will be really helpful.

 

Seriously, share this knowledge using the buttons at the top/bottom of the post.  It’s pure gold.

 

Shuttin’ up now.  Onward to Ryan’s post!

 

-Dan Hulsman,

 

VGM Academy

 

PS: A note to my American readers – Ryan, and many other VGMAers hail from the UK.  No, he did not misspell “Prioritize,” as “Prioritise,” multiple times in this article.  There are several words which use a Z in American English and an S in British English, so if you’re confused as to the spelling now you know!  I intentionally left the S-versions to avoid America-ing all over a perfectly good article.

Introduction

You’ve finally managed to agree a deal with a game developer! The contracts are signed and you’re excited to get started… but how do you actually get started on a project? Which tasks should you do first? How long is it going to take? How do you make sure you don’t miss a deadline?

In this blog I’ll discuss project management for freelancers (with a focus on Game Audio). I’ll break down the principles I’ve learned from the agile software development process as simply as possible and show you how you can apply them to your work as a Composer or Sound Designer (or both) in Game Audio projects.  

 

Everything discussed here is based my opinion and personal preference.
It works for me and will probably work for you, or… it might not  ¯\_(ツ)_/¯

One of the biggest problems I ran into when starting out in game audio was working out where to start on a project. My first big project, when I was just a wee slip of a boy, required a dozen pieces of music, nearly a hundred Sound Effects and hundreds of lines of dialogue to be composed/created/recorded. Overwhelmed by the amount of assets required, I threw myself straight to work “because hey, why waste time making a plan? I need all the time I have to focus on creative work. I’ll just pick it up as I go along, right?… right?”. Wrong.

I underestimated how long everything would take and floundered around trying to jump from task to task with no real idea of what the game developer was trying to achieve. Finally, after weeks of late nights and crunching, I was able to deliver everything I had committed to on time. The developer was happy but the whole process had been a complete mess and I knew I had to fix it.

To solve my woes and help me create a more structured workflow I turned to Agile Process Management.

I chose agile for a number of reasons:

1. Agile is a software development framework, and when you work in Game Audio YOU are a software developer
2. A lot of the studios I have worked with use agile (in some shape or form), so it would be easy for game directors to understand my workflow
3. Agile Development has a very short feedback loop and adaptation cycle. Specs and scope can change from day to day and the Agile framework makes change management a lot easier to handle

“Failures don’t plan to fail; they fail to plan”
– Harvey Mackay

Working Out Where to Start

When starting out on any project, the first thing I do, before grabbing a pencil and writing notes and melodies, before opening my DAW or Audio Editor, I perform arguably my most important task. I create my backlog.  

The Backlog is essentially a prioritised list of everything that is required in a project. This backlog of work is designed to evolve over time, allowing you maximise your output of work while adapting to incoming change.

In Game Audio, this backlog is your list of sound effects/music cues or lines of dialogue to be recorded.  Creating your tasklist/backlog is comprised of three main tasks: List, Estimate, Prioritise.

Step 1: LIST the Required Assets for the Project

In general this is a fairly straightforward part of the process, that involves gathering up all of sound requirements for a task. Depending on the experience/level of the developer you’re working with this can be a simple or laborious task. In my experience there are the great developers who will provide you with a detailed, itemised list of every asset required before discussing contracts and prices; There are developers who don’t have an itemised list but have a very strong design document and will work with you to build your list of assets; Finally, there are developers who have no idea of how to go about adding audio to their game and the emphasis will be on you to create the backlog. In any event, you will need to break down each task into as much granular detail as possible, including:

• What will the filenames be?
• What folder will the assets be stored in?
• What format will the audio be in?
• Is it stereo/mono?
• Should it be loopable?
• What size is the file? are there size limits?

Time invested in creating a detailed backlog is time well spent. The more you know about your requirements, the better you’ll be able to create an estimate of how long your tasks will take.

 

Step 2: ESTIMATE the Time Required

Which tasks should you estimate?

So you’ve now got a great big list of work to do. If you’ve followed along up to now then it might look something like this:

The next step in this process is estimating how long the tasks in your list will take.

As I mentioned earlier, your backlog is designed to evolve over time, as tasks are added and scope is changed. With this in mind, you should approach estimating the tasks in your list by focusing your effort on the most detailed tasks first and then work on fleshing out the less detailed tasks.  

The general idea is that the more detailed a task is, the more accurate your estimate for that task will be, so those are the tasks you should focus on. You can see an example of this in the sample backlog provided in the image above. Notice how the tasks 1, 2 & 3 are very detailed, I know exactly what sounds are needed and the context they will be used in, so I have a pretty good idea of how long they will take me. Compare these to task 4, in this example, it hasn’t been detailed very well, it’s a very broad task and at a later date will need to be broken down further when more details are available. This is typical of the game development process where different sections of the game are yet to be fleshed out fully and requirements are still being generated. This is why your backlog is constantly evolving.

Focus on the more detailed tasks while continuing to add detail to the more broad/vague tasks

How to estimate?

Estimating how long a task will take is mostly a case of trial and error, the more work you do the more you’ll be able to understand how long things take, however, the agile framework has some measures built in to help you keep your estimates on track.

As I mentioned earlier, the more detailed a task is, the more accurately you’ll be able to estimate the amount of time it’ll take you, but, let’s assume that all of your estimates are off by +/-10%, on a task that takes 30 minutes this isn’t too big a deal (although it can add up if you consistently under estimate) but throw in a 10% underestimation of a 40 hour tasks and 15% underestimation of a 20 hour task and you can soon find yourself hours, days or possibly even weeks behind on your deadline. To help avoid this, agile uses the “Bucket System”.

The bucket system is a relative estimation system, this means that it does not give you an estimate for the exact amount of time required per task, rather, it gives you an estimate relative to the size of the task thus allowing for a margin of error in your estimation. It is a very simple and powerful tool to help you organise your time.
The bucket system is based on the following scale of hours: 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100

Now all you have to do is fit each of your tasks into one of the “buckets” of hours. For example, you have a task to produce a finished piece of music and you think it will take you roughly 10 hours. This task will not fit into the metaphorical 0.5, 1, 2, 3, 5 and 8 buckets so you would put it into the next bucket up, 13.
As you can see, you now have a 30% margin of error in case you have underestimated. Of course, you may get this task done in 8 hours instead of 10 and this is where the trial and error of agile comes in. If you consistently find yourself overestimating then you can start to bring your estimates down and vice versa for under estimates. Over a few weeks and months you’ll start to find that your estimates get better and better.

As mentioned previously, another way you can improve your estimates is by breaking tasks up into smaller chunks. In this example, you could break down your task to create a piece of music into subtasks:

Create a piece of music

 

• Write and record the music – 5 hours

• Mix and master the music – 3 hours

• Create seamless loops from the music – 1 hour

• Final Edit and labelling – 1 hour

 

By breaking down your tasks as much as possible not only will you be able to create more accurate estimates for each step of the process, but you will also be able to identify any problematic areas in your workflow and can adjust accordingly.

 

Step 3: PRIORITISE your Tasks

Typically the priority of tasks will be dictated by the developer. Communication is key here and asking them what sounds they need most, or what part of the game they are currently working on can help you prioritise your tasks.

I’ll talk more about the prioritisation of task in the next section, where we’ll look at splitting your work into discrete cycles of time known as Sprints and show you how to calculate how fast you work.

Establishing a Productive Rhythm

This is where all of your hard work detailing tasks and adding your bucket estimations finally come together.

When working with agile, your work is divided up into segments of time known as Sprints. A Sprint can last anything from 1-4 weeks depending on the preferences of the team using Agile but is typically is 2 weeks.  

The key to the effectiveness of the sprint system is that it is timeboxed. You only have a fixed amount of time to complete your work, so (assuming that you don’t have the money to bring in extra team members) the only thing that you can adjust is how much work you add to your sprint.

So let’s assume that you are going to work in 2 week sprints (which I recommend), and you work 40 hours per week on your project. This gives you 80 hours of potential work that can completed. All you need to do now is take a bunch of your highest priority, most detailed tasks from your backlog (totalling around 80 hours) and put them into your Sprint Backlog.

You now have:

1. Your Backlog – A list of all of the tasks in your project at varying levels of detail.
2. Your Sprint Backlog – A *fixed* list of highly detailed work that you are going to complete in the next two weeks.

Now is the time you’ve been waiting for, it’s time to get to work on all of the items in your sprint backlog and start getting creative. Work as you normally would, take one task at a time and work on it until it’s completed, but, here is the important bit: As you’re working on a task make sure you record and log the time you have spent on a task. You can do this however you want as long as it’s done. There are several dedicated scrum timer tools and browser add ons to help you achieve this, however, I prefer to use the timer on my phone and log my time spent & time remaining in columns on a google sheet (where I keep all of my tasks) as I can share it with clients very easily and they can track my progress in real time.

Another factor to bear in mind, is that once you have added your tasks to the sprint them and started working on you should never change them. Never remove anything from your Sprint Backlog while your sprint is in progress and only ever add new tasks to your sprint backlogs is it is an absolute emergency and the client must have that sound ASAP. This might sound a bit draconian but there is a very good reason for this, as I am about to explain.

Calculating your Velocity (A.K.A Finding out how fast you can work)

Let’s imagine that you are just about to start a 2 week sprint. You estimate that you can perform 14.5 hours of work a week, giving you a maximum of 29 hours of work (or 29 hours of capacity) to fit into your Sprint Backlog. Next, you take 29 hours worth of tasks from your product backlog and move them to the sprint backlog. Finally, your sprint begins.

Fast forward to the end of your Sprint: You’ve only managed to complete 13 hours worth of tasks. Your estimated Capacity was 29, but your Velocity (the amount of work you completed was 13).

The first thing to do at this point is remember not to “Panic!!!”. It’s expected that you will either overestimate or underestimate your first few sprints. Agile is all about learning and adapting.
The second thing to do is take a look back at what happened during the sprint and work out what caused the discrepancy.

• Were the estimates you made for tasks correct? Were you massively over or under?
• Did you overestimate or underestimate the amount of time you could dedicate per sprint?
• Were there any emergency tasks added to the sprint? Was the scope of the sprint changed?

Take what you learned from your first sprint, write down your findings and then apply it to your next sprint. If you mis-estimated your tasks, then revisit the tasks in your backlog and adjust them up or down based on your findings. If you mis-estimated your capacity then similarly adjust it up or down to a more achievable level. Keep repeating this process Sprint > Review > Sprint > Review > Sprint  > Review > Sprint  > Review > Sprint  > Review…
With every sprint and review, you’ll learn more and more about how long it takes you to perform different tasks, and over time you’ll be able to identify bottlenecks in your workflow.
Maybe you thought you could write looping Fusion Jazz themes very quickly, but after reviewing a few sprints you might find that you always underestimate how long it takes you to mix Fusion Jazz (because dang it, getting the right sound from an organ can be tricky). In future you can take this into account and use a bigger bucket estimate for the mixdown process of that task.

The more sprints you complete, the better you’ll become at estimating your tasks and your capacity, this will make your velocity consistent with an ultimate goal to get your capacity and velocity on the same level – IE your estimates are spot on. When you get to that point you’ll be able to give your developers/project management a list of tasks and a due date…and they will love you for it.

Prioritising Tasks in a Sprint

Cast your mind back a chapter and you’ll remember that I said I’d expand on how to prioritise tasks in this section. Well….I’m about to do that.

Another nifty trick in the Agile framework is the MoSCoW prioritisation system. MoSCoW is an acronym derived from the four different prioritisation levels it uses for tasks: Must Should Could or Would It is a prioritisation system that focuses on delivering the highest value, most immediate business benefits early. In our case, we will use the MoSCoW system to get the most important tasks done at the start of each Sprint. First, let’s look at what each priority level means:

Must: This is a critical task that must be completed before the end of the current sprint.

Should: This is an important, high priority task, however, it is not necessary for delivery in the current sprint and could potentially be completed in a later sprint.

Could: This is a task that you’d like to complete if you have the time during this sprint but only if you have completed the must and should tasks

Would: This is a task you have agreed won’t be completed during the current sprint (IE. Tasks on your backlog) but would like to do sooner rather than later.

“How can I apply this to my sprint?” I hear you ask. When setting out your sprint, you should dedicate a maximum of 70% of your available time to MUST tasks. And fill the remaining time with shoulds and coulds. Allocating only 70% of your time to “MUST” have tasks will give you a great safety buffer in case of any sort of disaster or issues you might run into, ensuring that as a minimum you can always deliver the tasks you’ve promised and hit your key milestones and deadlines.

 

Conclusion

So there you have it, that was my (hopefully simple and straightforward) guide to agile project management for game audio.

To Recap

• Create a granular, detailed list of all of the tasks you need to complete
• Use bucket estimation to assign time estimates to your tasks
• Estimate how many hours of work you can complete in a fortnight
• Talk to your team and use MoSCoW estimation to prioritise your tasks
• Create a sprint backlog from your task backlog with a maximum of 70% of your total sprint time dedicated to MUST tasks
• Do some work
• Finish the sprint and review what happened, revise and adapt
• Repeat the process.

Remember there is no one-size fits all process. People work better in different ways and every project is different. Look at agile as a framework that can be used to structure your outstanding tasks and time but don’t be afraid to make changes to the process to suit how you work. The core principles behind agile are focused on analysing your process and adapting to improve your efficiency.  

If you’d like to know more about the process or if you have questions you can find me on twitter @rynde or you can contact me via my website: www.ryan-davies.co.uk