Shannon Mitchell is Vice President and Chief Operating Officer (C.O.O.) at Game Theory. Rad Magpie brought Shannon in to talk about Production with the Rad Studio 2020 and 2021 students - this blog is the result of that talk!

“At Gametheory, we make projects for change and for education. All of our projects and games have a social mission underneath. Something that makes GameTheory unique is that we’re a two-person company and we rely on the expertise of others across the game industry to make our projects successful. What this means is that when we have a client approach us with a problem – something that they'd like to try to solve or manage, or design – we pull together a unique team of different contractors and local companies in the area to make it happen.

In this way, being C.O.O. can often feel like high-stakes project management. It’s the same production skillset that you might apply to a single project, expanded out to the full company. It requires organization, and most importantly finding the right people to figure out the best plan. What it takes to make this plan achievable is scope management.

Every producer has a philosophy for managing scope

Every producer has their own philosophy for managing scope. However, as Kate Chironis put it, they usually fall into 3 categories. Do you relate to any of these?

I think all producers kind of waver between these three, but for me, I'm definitely very high on the happy Pikachu spectrum. I really love my work! Our model of having producers build a customized team to a project in order to solve an exciting problem together is something that's worked really well for us. Bringing unique people together for an exciting topic creates this energy that reverberates through the project and gives us a boost to make focused and successful projects.

In the past five years, I've produced 51 games like this, which is kind of crazy.

This roughly shakes out to 1 game per month. Many with an inflexible timeline and budget. On top of that, we most often work with people who aren't from the game industry. These folks approach us and they have an idea for a game or a problem that they need solved without fully knowing what it takes to make it into a game; It's all new to them. For each project we must carefully figure out how long we need to make the game and how much money and time it's going to take to get there.

Managing scope is hard

Because in my role, really, at the end of the day, it's up to me to make sure things are going to be done on time and to find the best combination of work that can get us there. I’ve worked carefully to create a process that has allowed me to proudly say that nearly every game we’ve created has been delivered on schedule and without crunch. When a project is delayed it’s intentionally rescheduled and replanned rather than a last minute missed deadline.

So what can you as a producer do to keep the work your team is doing predictable? Here are some rules I follow when managing scope:

Rule 1: Tasks needs goals. without clear goals, you won't be able to assess progress

When we think about scope, it’s natural to jump right into task-planning. But what's really important, more than even tasks, is goals. I truly believe that if teams took half the time they spend talking about tasks and switched it over to talking about goals instead, work or deliveries would be much more consistent. These goals make sense of why each of the tasks exist, and why they’re a priority in the vision of the project. Solidifying those goals on a high level before breaking them down into tasks is essential for maintaining focus.

If your goals are clear, anyone can build tasks to reach them!

Tasks can and should be the easy part of planning. There are always more tasks that can be made, but unless you know that they fit into the goals and what you're trying to achieve, it'll be hard to know why you should be working on those things and whether you're making progress. Having a goal like “Check that the stylization of all asset types mesh with the references for the project” can help make tasks like “Create one sample of each asset type” easier to define and prioritize.

Dana mentioned how essential acceptance criteria are when creating a plan, and she’s spot on. Knowing what “Done” means also becomes much clearer once your goals are locked in. When everyone is clear on what that final step of completing the goal looks like, these conditions become self-evident.

Define Your Creative Process

At the start of the scoping process you will have limited information to work with. In my work, a client might only give us a deadline that they need the project by. It becomes really hard to plan from only a start and end date, and many producers make the mistake of trying to plan the best use of this time on their own.

Instead, it’s essential that you involve your team in this planning process to make sure that the plan you commit to is realistic. I like to start with goals, and then milestones to make the process into more manageable chinks. Ask yourself "okay, what are the pieces of our timeline? What are the big steps that we need to take to be able to reach that final delivery?” Be specific and define what makes up each of the milestones and what requirements make sense for them. “What does Beta actually mean? What needs to be done? What pieces of the design are essential for release and what’s the best way to work towards those?

To visualize this timeline planning, I imagine milestones (For this example Prototype, Alpha, Beta, Release) as buckets that I can drop different requirements into. I use these buckets to sort through the work into portions that feel connected and sensible.

Here's an example of I might start to figure out what we're going to be doing when and starting a project plan. To begin, I plan out those essential parts of the project. In this example, I know that we will quickly need a core loop to test the flow we’d like. It's not going to work unless we have our loop set up and we don't have an art style, so maybe we need to do some style tests. It feels like testing these out will give us enough to move forward, so they fit together to form the requirements for our Prototype - the first phase of the project.

When thinking about what might fit for Alpha I consider “What are the goals that will get us the bones of the game? What are the highest value, least intense goals that we can set for Alpha?” Most importantly I try to ask “What needs the most time to refine, iterate upon, and test?” In this example, the narrative arc, the UI layout, and any different modes for the game should be created sooner rather than later, are essential and require iteration and extra testing, and therefore fit nicely for an Alpha goal.

And then Beta, I aim for requirements that are less risky, but equally important, and fun little add ons. This is often where tutorialization can come in, additional content like collectibles, and polish. Finally for release - I define the process to check every part of the game to make sure no requirements were missed, and that we know it’s the level of quality that we planned for.

Regardless of your requirements, the most important thing to know is your final deadlines. Everything in between is flexible, and scalable to meet the best mix of features, value, and appeal. Know that it’s best to try and swap around options to figure out what the ideal scope is for your team and your project. Scope is more than the vision of the project, it's how those pieces of the vision fit together for the exact circumstance of your project.

Even moreso, with agile development expect that what your vision looks like can and will change. Goals can never represent the full picture of what the game becomes. Your vision can and should shift.

Rule 2: Be honest about the vision, and don't rely on "stretch goals" for progress

Creating a timeline is only useful if you’re honest about the reality of your vision. I often notice teams setting stretch goals really early in development rather than being precise about what is and isn’t part of the vision for the completed product. Often this can come from lack of confidence in their planning. It might sound like "Oh, well, we'll just try for this. Maybe we'll do it, maybe we won't." or "we'll just try this week and if you don't get yet, it's fine." or, "I can probably do it. It'll be a big week, but I just want to get it done."

In reality, sprint stretch goals often cause crunch on otherwise functioning teams. These goals are a symptom of an unclear vision, or lack of confidence in planning towards that vision.

When stretch goals are set, high performing teams will put pressure on themselves and dedicate excessive time to make the goal happen. On the other end, too, sometimes I'll see producers set really important goals as a stretch goal or as a stretch task for a sprint instead of being upfront about the importance of that goal. Then they'll feel really bad if their team doesn't reach it, even though it was technically a stretch goal.

Frequent stretch goals are often used to avoid honest conversations about how much work is realistic.

Stretch goals unfortunately take up the space of just having a real conversation about what's realistic. Instead you need to go out on a limb and commit to a plan by saying, "here's what we know we can get done to reach our goal.” While doing this, keep working on estimating if something is feasible and following up. You won't always get it right, but I think it's better to either have a sprint where you don't get enough done or a sprint where you find out that you overcommitted and still have some tasks left open than “technically” hitting every sprint while not being entirely sure what you’ll end the sprint with because of stretch goals. Likewise, knowing you’ve missed a goal or under scheduled gives you clear information that you can learn from and use to get better.

In approach, aim for sprints that have a set amount of work and take the time to be really clear about what work is required.

Planning scope is an exercise in consent

As a producer, I'm not a programmer. I'm not a designer. I am not an artist. If my teammates tell me that they can't do something this sprint, I will trust them. And that's really the end of the story.

Scoping is only possible if you can trust someone to tell you honestly that the plan isn't going to work. It also requires trusting people if they say the plan can work.

If somebody tells me: "I know it's a big goal, but I can do it this week," even if I'm worried about it I will let them take on the work. Because I trust them and take what they say seriously.

As a team, when planning and scoping we come to an agreement on what's doable and what isn't. When doing this, everyone on the team needs to agree to commit to the work or else we don’t include it in the plan. As a producer, you should never feel like you have to push somebody to take on something that they don't think they can do. Overcommitting, pressuring, and not allowing others time to agree to a plan will cause strain, team dysfunction, and will vastly impact the reliability of your plans.

Because of this, it should not just be up to the producer to figure out the scope. Producers can’t know it all. You have to be able to rely on those around you as experts and as team members.

I really rely on my team whenever I'm scoping something out. You cannot plan in a vacuum.

Sometimes this is hard, mostly because people don't really like talking about scope. It can be stressful. But I do think that project planning is creative work. And as creative teams, you can get really creative with how you're talking about scope, which makes it easier to figure out. It makes it a little bit more fun!

An image with greyed out time blocks that represent the hours in a sprint

Check out an example from one of our projects! Our team hates long documents, which is fair, I suppose. And they hate doing spreadsheets of estimates and things like that. So one thing we’ve tried is to make a drawing to represent the scope.

Let’s say we have 200 hours budgeted for a project. We draw an icon to represent each and chart out what part of the process the time could go towards. Then when we start to talk about features we can look at this and ask “How big would this be in comparison to the rest of the project? How much space does it take up?”

This approach is more visual, and definitely more fun than just adding numbers to a spreadsheet.

There are times when your goals and your tasks are really obvious, but your team may needs a little extra push to think about how much effort the work might take. Sometimes we’ll break down those “harder” and less desirable tasks and assign different reward levels for it. Some tasks we'll categorize as “dragons”, which are really hard tasks.

When task planning it gives us a more tangible way to talk about it, and a fair reward to make it worth the effort.

“Oh, I think this is going to be a dragon, it's really hard, but if we do it, we can have, you know, a late morning or we can have a treat or we can have a little break early."

These different rewards offer that extra push for really hard things. This extra terminology and creativity when describing tasks helps make it more fun. It also helps keep people honest since it removes some of the pressure around scoping by making it feel more like a game.

You can think about scope management like a game.

For all creators, scoping is easier to manage once you realize the similarities it has with creativity and game design. Keep these similarities in mind to make sure your scoping process is as effective as possible.

What’s your loop?

What is the repetitive process you follow together? What are your milestones and what happens at each? Sometimes people will alternate types of sprints. So there will be something like we'll do an initial build and then the next group will critique it and we'll do an iteration on that. So think about a repetitive process that you all can follow together, like a game loop.

Keep testing!

What works for one project will not work for every project, how are you checking in? Testing is so important with your process, figuring out what works for people and what doesn't.

Advance or Try again?

At what point do you move forward with the project, goal, or feature vs starting over with a new strategy? Avoid getting stuck in the same place for too long.

Pacing

Are we as a team stressed or are we at a comfortable level of difficulty? Do we have time to enjoy what I’m working on or do I feel rushed? Does collaboration feel creative and open?

Growth & Reward

If things are going well how is that acknowledged? How can we celebrate progress made?

Reflect & Adapt

Make sure your process serves you, there are so many ways to create! One thing I found works really well for managing scope is critiquing work often. I try to create opportunities where everyone can show off their projects, and receive encouragement and recognition for what they’ve done. Another way to adapt might be adding an extra question to your daily standup such as “How are you feeling about the project?” or “How can others help you today?”

There are rules to Agile and Scrum, but be creative and flexible within those rules. Do what works best, which might be customizing the process for your team. Keep your options open, and listen to what is and is not working. A process that serves your team will help keep scope in check.

We know that rewards are important in games, they’re just as important for teams!

I'm a firm believer that you need to treat yourselves and your team members when you're in a team or when you're on a hard project! Work at creating balance with how you manage scope. Sometimes if we have a really hard sprint, I'll plan for the next sprint after to be one where we focus on one of those fun features or “lighter” features that we've been waiting on but haven't had time for.

Think about ways that you can reward the team for working well together and having fun, either as part of your schedule or added bonuses that keep people motivated.

Think beyond the hard parts and notice if you’re excelling beyond what you originally scoped for. For example, if you keep meeting your sprint goals, or if the current pace continues or increases, what does that mean for the game? Are you just going to keep going? Or are there still things that you can explore? Can you reduce your pace intentionally to make better use of the time you have and increase flexibility for the team?

Or - if you fail a couple sprints in a row like, what can you do to start fresh and try again? How can you shift it up and come up with something different?

Project planning is not exactly like game design, but I think a lot of the principles of game design still go with project management. It really comes down to just listening to the people you're working with, listening to, you know, what they need and what makes them happy and how you can balance the challenge with reward.

Scoping can be intimidating! The key is to know the principles of planning, know what you need to get done, and from there figure out what about that process really works for you. If something isn't working, talk about it and see if there's another alternative that could work just as well. I think it's okay to be flexible, but you know, the only way it works is if the entire team is involved in that process and you're taking those decisions really seriously.

Tip 3: Over-committed? Don't "cut scope." Change scope.

Every team will hit that point where frankly, we overcommitted. You've been working on something and you have these goals that need to get done, but the deadline's coming up and you're not sure if you're going to be able to make it. What should you do?

What you should know when scoping down is that generally, you can't just remove one thing from your backlog. You can't just cut something. Otherwise you will be left feeling like “I’m making a slightly worse version of the game.” To avoid this, you need to rework the whole vision of the project to support that change so that what you come away with still works.

The Sunk Cost Fallacy

As humans, the way we think is that if we've already put time into something, we will continue supporting that thing rather than looking at the future time that could be spent somewhere else. We rarely want to lose work, even if the work isn’t serving us. We want to take care of it and keep it even if it gets harder and harder to support. This principle of human nature is so important to be aware of because it’s natural. However when scoping, it's one of the hardest hurdles to get over.

We get caught up in what we’re losing, and what we're leaving behind. To overcome this pain of lost work, it’s necessary to refocus on a new and different future vision of the project. Take time to recontextualize the change and define a vision that works even better for you.

Let’s take an example: If we're looking at this timeline that we made before, let's say we are coming up on the Alpha deadline.

We made our core loop super fun, people love it. We did some art tests, people liked the style and then we've been working on our menus. Those are all set up, but we aren't sure if we're going to have time to do our whole narrative arc, test it out and have some game modes that we can test for Alpha. Those two things feel like they are hard to both get done for the deadline.

The first step is to realize when that's happening.

I think a lot of people would look at this and would just say, "Well, we either can't have a narrative or we can't have game modes, and that's the only thing we can do." But really, just losing one of those things can make the rest of the game fall apart, right? Like, if you don't have your game modes, maybe your collectibles don't make sense anymore. Same with the narrative. What goes into the tutorial if the narrative isn’t part of the game?

Games, like all things, are interconnected. If you cut something, it has these massive ripple effects that your team will feel. Instead of cutting something and keeping all else the same, it is actually better to reset and start your vision fresh with this new information. Instead, for this example think about how we can redo these features and come up with something new.

A lot of times when people talk about cutting scope they think it means “The same version of the game I want, but worse.” Which is not true! When you change your scope, you should be closer to your game vision.

Look hard at the options and come up with a whole new version of the game so that it can take less time/ risk while still serving your original goals.

So - maybe instead of having a whole narrative arc, it's okay to still just have some narrative context and use that to reach your original purpose. It won't take as much time, but will keep the heart and spirit of the narrative. Maybe you still want to have these game modes because that's what players are really excited about and what feels core to the concept. However, since you’ve reduced the scope of the narrative and are leaning into the game modes more, skins might start to make more sense than collectibles. That could work better to showcase the different game modes and display the narrative roots of the characters in new ways. Instead of a narrative tutorial, you could work on a practice arena where people can try out the different game modes and learn actively.

You can start to see - if you reduce the scope of one aspect of the vision, you need to look at all of the different features that are impacted to redesign and reimagine them. And as always, check in with the team throughout to ensure that "Yeah, this new vision is good and we like it and we think it's going to work better."

This process will take time. You have to communicate a lot. But usually you come up with a vision that is better than the original. And that's the thing:

There are so many ways to make a good game.

Instead of “make the same game but worse” it should be “Make a different version of our vision that fits with what our resources are.”

This is the main lesson I’ve learned from creating so many little micro games. There are tons of ways to approach a concept. There is no singularly perfect vision of your game that you have to protect.

Use that knowledge as fuel to explore the different paths that you can take to reach your goals. You will find a scope that fits with your team, for your talents, and for the time that you have.

A video recording of the presentation will be shared here when we have completed our editing process. Don’t worry, you’re not missing any content in the meantime: all of the information has been transcribed into this blog post. However, we intend to share recordings of each presentation for those who would prefer to listen along. Check back soon if you’d like to watch the video.

This blog post is based off of a portion of the 2021 Rad Studio Online curriculum. Rad Studio 2021 was a fully online summer program for game development students, and the information above was shared with the cohort of emerging devs during a workshop session. We’re making this information free and available to anyone who’s interested in it. You can learn more about Rad Studio and this initiative here.

RULES OF USE:

Feel free to share this information with others! We ask that you cite Rad Magpie (and any relevant linked sources) if you use this for your class / workshop / etc.
If you find this useful and are financially able, consider making a donation to Rad Magpie. We’re a 501(c)3 nonprofit organization and rely on the generosity of our community to continue producing resources like this one. Learn more about Rad Magpie here.

This blog was written by Shannon Mitchell and edited by Megan McAvoy

Lessons on Production & Scope