Easy Gamedev Planning – The Agile Way

Originally posted on laurabularca.com. Follow me on Twitter for a lot more #gamedev tips

Ah, project management and planning! These words have been known to freak out a gamedev even more than the dreaded marketing. I mean, who wants to write down schedules and todo’s when you can design, code, make art instead? Developing games is all about passion, spontaneity, and we all know creativity is impossible to control, right? And this is all somewhat true if you make games as a hobby. If instead you actually mean to build a livelihood out of making games, that’s a different matter. And in that case, you’d better plan and manage your game, or else you set yourself up for failure.

Found on The Internetz

Here’s a little secret though: project management and planning in game development is Fun and Highly Creative. It’s one of the most rewarding activities out there, but also one of bad history, bad fame and heavily underrated. You CAN be passionate about game planning, and it definitely requires a lot of ingenuity because, if you think creativity is hard to control, wait until you need to keep a team of creative, passionate gamedevs motivated and on track over large periods of time. And it is Fun because you don’t get stuck in one single role and one single mindset. You might not code, make art or design as much as you wish, but you are a crucial part of EVERYTHING involved in making your game, which grants you a wider, stronger perspective than anyone else in the team.

This being said, how DO you plan a game, exactly? And what does project management really means? Before we begin breaking down various methodologies and tools to do that, here’s some fundamental things to keep in mind:

So, let’s begin. Figured I won’t be able to cover everything in one bit so that’s why this is The Agile Way, aka – hopefully – Part One. Now… Wtf is agile?!

Found on The Internetz

Agile Fundamentals

Watch this. It’s funny, isn’t it?  But this is not for fun. Donkey conveys the essence of agile methodology, which is constantly asking, Are We There Yet. Your focus is building a minimum viable product that can quickly be sent out there to real people who can provide real feedback. Then iterate based on that, quickly moving closer to a finished game that successfully offers what you had in mind to begin with. Agile means always having a working build of your game, and always prioritizing people over processes – aka show your game fast, get feedback from real players, iterate based on that – rinse & repeat, Are We There Yet?

Like any methodology, the agile game has a few fundamental definitions, rules and roles. The gamedev darling set of rules and roles in agile methodology are called Scrum, a term borrowed from Rugby. So remember: Agile is a methodology, a philosophy, if you wish (always asking Are We There Yet?) while Scrum constitutes the rules of the game (in what language, with which frequency and tone can we ask Are We There Yet?, in a manner good enough not to make Shrek toss us out of the carriage mid way, or worse). Now, some definitions…

Definitions

A backlog is a list of stuffs that you need to do in order to get where you want to go. It’s like a shopping list, only you’re “shopping” for the ideas, features, gameplay, art and sounds which have to be made in order to bring your game to life.

A backlog must be prioritized, so you put the mandatory ingredients on top of the ToDo list and the nice to haves at the end of it. The reason for this is so you can drop the least important stuffs from your list, if you end up short on dev time.

In agile, the stuffs in the backlog are called user stories. That is because the rules of agile aim to put you in the player’s shoes, focused on real life value and not on bits and pieces of individual work, which cannot stand by themselves. That’s why instead of building your shopping list with stuff like “EnemyAsset_satyr_anim_chase_set” or “Satyr hearing perception”, you ought to write: “As a player, I want to encounter an enemy which looks and feels like a Greek mythological satyr” and “As a player, I want to be spooked when I encounter satyrs which is why they have to have a good perception system, be aware and react properly when I am nearby” (thanks, Guru Games!). These user stories are harder to write, but they serve an exceptional purpose, which is to always keep yourself and your team aware of what you really want to offer to your players. Perhaps more importantly, the user stories are not discipline-friendly,  which means they actually make your artists, your programmers and your designers communicate about the feature at hand and work closer together to create something that can actually be played. The added bonus is that no one gets to stray away from the main purpose of your project, and that’s awesome.

User stories can be detailed into Tasks, for the ease of work distribution. Most user stories involve lots of different skills, so its common to split them into what the artist does, what the programmer does, what the designer does, and how will they go about putting their work together so it becomes the thing that the player will experience. But remember, this is just for their convenience. Doesn’t help much that you have an awesome 3D model, if it doesn’t move properly, makes no sounds or is dumb as frak. The player cares about your awesome monster in its entirety, so everyone in your team must work together, carrying that responsibility in mind.

Pro Tip: A good backlog looks a lot like a good design document. If you read a good backlog, you will understand, as a player, what you are about to experience.

Now that you have your user stories all neatly listed and prioritized in a bucket, it’s time to do the job. Which is when Sprints (sometimes called Iterations) come in. Sprints are time boxes, set periods of time. They can be established as one week, or two weeks or more, but they never change.

A Sprint starts with something called Sprint Planning, which is where gather your team, you look in your backlog and pick the user stories you think you’ll be able to finish, together, in the time box you have commonly set. Since we are talking about quantifiable time here, the sprint planning is also an excellent moment to estimate your user stories.

Estimations are nice things in agile methodology. You don’t estimate in time, which is pretty awesome especially for young, inexperienced teams who actually have no idea how long it will take them to do X. As a matter of fact, most experienced teams have the same issue – just look at Molyneux or Double Fine  or any game you know was ever delayed. So agile tosses the whole time estimations away, and proposes Points instead. You use a Point scale, where you estimate your user stories from easy to somewhat complex to medium difficult, to kinda real difficult to complex as hell to impossible to estimate. While it is common to use good ol’ Fibonacci as a Point scale because it has a proper increase in quantification (0 for trivial, 1 for quick and easy, 2 for mm bit harder, 3 for kinda complex, 5 for really complex, 8 for OMG this is gonna be a tough one and so on), you can choose whatever point system just as long as you can use it to relate between stories.

Pro Tip: Personally I recommend the easiest point scale which is 1 for easy, 2 for medium, 3 for hard, that’s it. If you can’t assign 1, 2 or 3 points to any user story, this means your user story is too big and needs to be split up.

The trick here, the reason you are estimating by assigning points to each of your user stories is so you can figure out how many points you can get done, as a team, in a sprint. The amount of points you are able to deliver at the end of a sprint is called velocity – and it is your velocity, as a team: how fast are you working together, how many points can you accomplish in a given time frame. Now this is the kind of information that can save your asses, really. The velocity is crucial to know for a happy, productive, passionate game development team, because, when you get close to the finish line, you will know enough about yourself to understand if you are able to finish, or you’ll know in proper time if you need to cut some stories from your backlog. Your velocity will guide you throughout the project, will ensure that you have a good pace and that you are on track. It will warn you of problems, it will keep you real, and it will teach you to work better together, as a team. So, your goal is to have a way of planning that gives you an accurate velocity. In agile, the velocity is always a median of points done between all your completed sprints, so the more you maintain your backlog, the better you estimate your stories and the more conscious you are in updating the status of your stories, the more accurate of a velocity you will have.

Finally, a Sprint also ends, which is when you count your Dones and Not Dones. This phase is called a Sprint Review, and it should ALWAYS be done with a working build in front of the entire team. You should have all the user stories you agreed you’ll do during Sprint Planning in front of your eyes, and pick them one by one and see if they really happen in game. If the team agrees a user story is happening, you mark it as Done and yay, you earned some points for that sprint. If instead a user story is not done, figure out why, and push it to the next sprint. Rinse & Repeat.

There’s one more thing in agile called Milestones. A milestone can be a calendar date (ie: GamesCom) or a well defined stage of the game (ie Beta, or Get all core features done), or, most commonly, both (you need to present a stable, feature rich build at GamesCom, right? You must have something to Show Off.) By the way, Releasing your Game is a Milestone, probably the most important one ;).

Found on The Internetz

Roles

There are two common roles involved in agile, which are Product Owner and Scrum Master. The theory states that these roles cannot be held by the same person, but in a small team you gotta make do.

The Product Owner is the person responsible with the overall vision and scope of the game. It’s the person who deeply understands what must be done and why and how, the one who can say if a feature feels proper or if a menu button is in the right place or if a texture is in line with the project’s artistic goal. He typically adds user stories, or removes them or points out those which need refining.  The product owner is your players’ advocate, and sometimes he/ she can be known as game director or creative director.

The Scrum Master is the poor soul who makes sure the plan is maintained. He/ she is the book keeper of your time, the one who talks to everybody, makes sure all the stories make sense and that everybody is fully aware of what they have to deliver, and how and when. The Scrum Master is also the gentle whip who makes everyone update their user stories and tasks, as well as the one who yells FIRE first, when it becomes clear that you won’t be able to complete all your user stories in time.

Each user story can also have some roles involved. Typically, each story has a requester, which is the person who deemed the stuff noteworthy of doing – that person is frequently the Product Owner, but it can depend on the prerequisites for the job and/ or the manner you decided to assign responsibilities. For example, you might need a dev tool to ease up the designer’s job, in which case the requester is a designer, and you will write the user story a bit differently: As a developer, I need…... Or you might have decided to trust your sound guy for everything sound related, in which case sound heavy features might be requested by him. Treat this part carefully though, to avoid any unwanted misunderstandings.

A user story also has an Owner, which is the person who took the responsibility to get the job done. Multiple people can be involved in bringing a user story to life, but the Owner is the person who should feel really sad if the stuff’s not done by the end of the sprint. This means that a user story’s Owner must have all the support needed especially when it comes to the team members he or she needs to accomplish the stuff.

Pro Tip: Distribute Ownership in a balanced, democratic and, preferably, equal way.

Found on The Internetz

Rituals

The agile way has rituals, designed to make sure the ball really rolls. The rituals are:

Building the base of your backlog, which is when you fill your backlog with all the stories you can think of in order to complete your game. This has the potential of being a long, long meeting, or even several meetings where you pre-plan your project and put on paper what you actually want to do. This is when you also prioritize the core of your game, the essential stories that define your game, and for some basic blocs, you might even have some understanding of the actual work ahead, in which case you can even estimate. This phase goes hand in hand with concept work, prototyping and establishing the pillars of your design. Once you have your wishlist bucket, you decide which of that long list of user stories constitutes your minimum viable product (the minimum set of specs with which you can launch your game), and so you proceed to Sprint One.

Frequency: Once per project.

Pro Tip: The base backlog building ritual also is the perfect moment when you can review the year ahead, and contemplate your marketing strategy, which concretely expresses itself in what gamedev events you want to attend (where you will want to have a nice, stable build to show). Set those event dates as Milestones and throw them in your plan. Keep them in front of your eyes, and your team’s eyes, so you don’t end up crunching 2 days before GDC starts or what not. I can’t even begin to express how much time and pain this practice can save you.

The Sprint Planning meeting where, at the beginning of each sprint, you gather your team and you jointly agree what you will accomplish during the given sprint. If you set your sprint length at One Week, this means you start each Monday with a Sprint Planning ritual. This should be an action oriented meeting, which should not last too long, as you should theoretically just review the user stories in your queue,  perhaps re-prioritize a few, and play a Point estimation game for the stories not estimated yet.

Frequency: Once per Sprint ie Once every Week.

Pro Tip: Obviously, as Sprints go by, the Sprint Planning meetings get progressively shorter, but also as you get close to the finish line, and you have to face bugs or unforeseen stories, the Sprint Planning meetings can get a bit longer again. But by the end of it, you should really master teamwork and communication 

The Daily Check-up is a 5 minute Standing Up meeting where you make sure everyone on your team knows what they need to do, and that they are not blocked by someone else. Blocked means a coder is sick and so the support he had to deliver to a designer is delayed. Or that an artist underestimated a model so he won’t be able to push it to your animator. These all have micro impacts on your plan, which might seem small enough to ignore, but keeping track of them has immense long term value. These also serve to glue your team, and to teach each other to be effective.

Frequency: Every Day!

Pro Tip: DO NOT allow daily check-up meetings to go over board. This is NOT the time to discuss long term plan, business opportunities or team misunderstandings. It is also not a progress check per se, people do not have to detail what they worked on yesterday, but instead be brief and focus on issues that block them or otherwise stops them from completing their stories. Also: if your dailies usually exceed 15 minutes, you’re doing it wrong.

The Sprint Review happens at the end of your sprint, with a Working Game Build in front of your eyes and a list of user stories market as finished, that you need to check. Since you time boxed your sprint in digestible chunks (hint: don’t set your sprints to one month, please!), your list of stories shouldn’t be awfully long. Plus, if you invested time to write proper user stories, what must be checked and what DONE means should be obvious for everyone. So the Review meeting is a bit longer than 5 minutes, but since its very action driven it should be short and sweet, too. And you get to play Your Game, Together! Fun, no?  See, it all ties up.

Frequency: Once per Sprint ie Once every Week.

Pro Tip: Do NOT prepare a sprint review build 5 minutes before the meeting. Stuff breaks – make sure you are ready, thus respecting everyone’s time.

Pro Tip via Sebi: Spare a moment for a Sprint’s retrospective that focuses on how people FELT that week. Was it boring, fun, stressful, awkward? What can you do to improve the mood next week? It helps and frankly, it’s kinda nice to ask and be asked how stuff went.

The Milestone Review is when you need to be done with a crucial part of your game. It’s like a Sprint Review, only things here need to be Perfect, Polished, Ready for your goal. So when a Milestone is getting closer, make sure you include time in your plan to test and bug fix.

Frequency: Typically once every few sprints.

The End!

Well, actually. These are the absolute basics, the minimum minim of being agile. There is A Lot I left out, like the Icebox, The Epics, your Burn through rate, ways of labelling and categorization, charts and histories, and how to accommodate feedback, how to review your priorities, how to treat mundane tasks aka chores, how to treat your bugs, and so on. Furthermore, there is an entire saga that can be written about the many various software tools that you can use, not to mention the Manual DYIs like lego boards (yes, you CAN use lego to plan agile, tru story).

I wrote a second part focusing on my tool of choice, Pivotal Tracker. I'll publish it too if I get enough feedback here!