• C Blake Smith

Beginner’s Guide to Audio in Scrum Environments

As a senior at DigiPen, I’ve learned a lot about the many aspects that go into creating video games, including different types of project management methodologies. In Fall 2019, I acquired my Professional Scrum Master (PSM) 1 certification, marking me as understanding the basic principles and functionalities of Scrum. One major disconnect I discovered while learning more about Scrum is that audio pipelines of game making doesn't align with Scrum, at least not at first glance.


Scrum is one of many methodologies in the Agile framework that supports complex projects within complex environments. At the heart of Scrum is the Sprint. Sprints are one to four weeks long timeboxes where work is determined as the team pulls tasks from their Product Backlog and puts it into their Sprint Backlog and then turn them into potentially shippable items. Additionally, Scrum supports several ways to measure the velocity of the team, allowing for consistent planning. This process helps to reduce risk and increase efficiency, which is why many game studios have integrated Agile/Scrum into their software processes.


One might think that audio doesn’t really fit within Scrum, but the cool thing about Scrum and Sprints is that they’re a flexible framework, you just have to put yourself in the right mind for it. For the beginners who are new to working in an Agile environment, I’ve organized some ways we as audio asset creators can better integrate our processes into Scrum.


1. Create Categories for Development Stages


Creating Sprint tasks that cover conception to completion is setting yourself up for failure. There are too many points along this process where you can be bottlenecked, which can result in not completing your tasks for the Sprint. This can have a ripple effect that causes the team’s trajectory to no longer be accurately reflected in the actual burndown chart.


Instead, subdivide the tasks to simplify it. For sound effects (SFX), I recommend the following subcategories:

● Record Foley

● Edit/Mix SFX

● Implement into Middleware (if using middleware)

● Implement into Engine

Ex.








For voice overs:

● Record

● Edit

● Implement into Middleware (if using middleware)

● Implement into Engine

Ex.








Music is a bit more complicated, like art, and having smaller iterations helps keep things moving. I found the most success with:

● First Pass

● Second Pass

● Final

● Implement into Middleware (if using middleware)

● Implement into Engine

Ex.








These categories support a simplified breakdown of the work that allows an incredibly long process and makes it more suited for Sprints. These are suggestions, of course, so there are many ways you can change to fit your project’s needs. I greatly encourage including at least these categories on your Scrum tasks.


2. Group SFX Into Related Categories


We often look at our huge list of SFX that we need to make and consider them independent and separate from each other. To better integrate audio into Sprints, we should approach task breakdown of SFX in one of two ways:


1) Make Sprint tasks for each SFX you need to create; or


2) Group them together based on a mechanic, a character, an environment, an item, etc. that connect them.


For example, by grouping all of the SFX related to a scoring mechanic into one task specified by a “Scoring-related SFX” leading tag, you can then list the SFX specifically noted in the description of the task.








Here is an example of coupling the category of the SFX with the stage of development it is in.




















3. Estimate Based on Size, Not Time


Most Teams using Scrum use some sort of estimation standard. This is how you can determine the velocity of the team and forecast how much work is feasible per Sprint. I’ve found that using time to measure how long a task will take is too restricting and often made it feel like I was failing to deliver consistently.


I use the Fibonacci sequence (1, 2, 3, 5, 8, …) to divide up the sizes of my tasks with audio production into points. Each number is associated with how much has to be done for a task to be considered complete. This does require some analysis of what the task entails, and how that effort related to other work like it, else it will make it challenging to do other estimations.


The reason behind these numbers is that a task that’s estimated to be 2 shouldn’t be much bigger than a 1, but a 3 should be more than twice the size of a 1 and therefore take more effort to complete.


This is an example of my estimate sizes:

● 1 Point - Implementing basic assets into middleware that have no complex functionality; Foley ambiance sounds

● 2 Points - Mixing or editing less complex SFX; Basic implementation in engine

● 3 Points - Implementing VO into middleware or engine; Prototyping in middleware

● 5 Points - Recording VO; Implementing adaptive music into Middleware

● 8 Points - Editing VO; Creating music

● 13 Points - Implementing complex adaptive audio feature into engine

● 21 Points - Too big, break it down into smaller tasks


I created these estimates to align with how I work and you should tailor this to fit your workstyle and your project. After a few Sprints you’ll have a better picture of what these numbers mean to you, so don’t fret about having perfect estimations from the beginning because you improve their reliability as an estimate as you learn more about the work and the relative size of the different items to each other - smaller and larger.


4. Don’t Be Afraid to Plan Out Just the First Half of the Sprint


Believe it or not, this is normal in Scrum. If you think that a certain mechanic won’t be integrated until the latter half of the Sprint, leaving you with very little time to get the assets made for it, don’t include that task in the Sprint. One of the flexible elements of Scrum is that you’re allowed to add tasks to a Sprint. You can remove a task as well, but definitely have a long conversation with your Scrum Master first.


That being said, do have a goal for what you want to get done next. When adding your tasks to the Sprint Backlog, you are forecasting that you will be able to get them done within the duration of the Sprint. When you over or under prepare for the Sprint, you’re doing yourself and your team a disservice.


If you’re able to, always plan to create assets for something that’s been implemented in the Sprint after it’s implemented into the project. Ideally, the team has a placeholder audio asset to use until you’re able to make “the real thing” assets (my team used a simple half-second long triangle wave until I could get create and implement the real ones).


Using this approach may mean that sometimes you’ll be starting and finishing assets as well as implementing them in one Sprint and then wonder what’s the point of breaking up the process. We do this breakdown because we don’t always know what’s going to happen. If you’ve recorded 20 Foley assets, edited all of them, and have them implemented in the audio middleware but weren’t able to implement them in the engine for any reason, your progress shows that you’ve accomplished three Sprint tasks instead of not completing anything. In Scrum, work in progress (WIP) (AKA not done!) does not count toward the delivered work at the end of the Sprint, so it’s like it didn’t even exist.


About the Author


Blake Smith is an Agile advocate who also has the benefit of being a passionate musician, composer, and servant-leader all rolled into one. He has been helping teams in the restaurant business and within video games achieve greater success for the last 10 years, but only recently realized that being Agile was the best next step for both himself and to help others around him accomplish greater things.

0 views

© 2019 by Blake Smith. Proudly created with Wix.com

  • LinkedIn - White Circle
  • SoundCloud - White Circle