Using SCRUM in indie game development

Introduction

For Hover Cabs we choose to use the Scrum-ban methodology to manage the game development. This post is not to explain you how SCRUM actually works, since there are a lot of free sources on the Internet that will explain it better than us.This post is to share the way we implement it since there is not so much information for small teams. From our point of view the best of this methodology at the very end is:

1. each team member is responsible of the project

2. you will foster learning more than the game itself

those principles, as you can easily notice if gamedev, are criticals for every team. We all know that a good game can be successful, a bad one will surely not. At the end of the day, the team is what remains in a company, and it grows up with its experiences. In every case the team should learn a lot, to take the maximum advantage independently from results. Responsibility and learning should be strongly encouraged, and SCRUM marries this philosophy perfectly. The kanban is an enhance which gives a clear visualization of the work stages.

Personas

Our workflow starts with Personas which are descriptions of possible players. We have to start with some assumption, since we do not have any player yet. Write down imaginary profiles for our future players helps us to drive the design toward them: that means to play better with engagement and retention, design side. An example of Persona:

John, 28 years old car mechanic from U.S.A.

He wants to have the time to play games, but he hasn’t. Anyway he owns a Nokia Lumia 520 and loves to download free games to play while at job. He cannot spend too much time and he is more likely to play during pauses at work. He has friends on Facebook and doesn’t use to pay a cent to play freemium games.

Goal:

Personas will become Play Personas once the game is released and we will get a clear idea of their behavior through tracking and direct feedback.

Stories

Basing on Personas we wrote down the concept document generating player’s stories: those are a great way to divide the problem into subproblems in order to conceive all the tasks each member of the team should satisfy to solve it. Here it is some example of story:

we use to distinguish the players in 3 categories:

1. newbie: the players in the first day
2. casual: the players with normal retention and low engagement
3. advanced: the players with high retention and engagement

Every Sprint has the goal to solve a set of stories which are chosen from the product backlog and considered to satisfy the basic Sprint goal: to develop a potentially shippable game. Each story is enriched with a class of metric that will be tracked and we use the categories suggested in this post.

The Kanban

Four our kanban we use the typical  four columns:

As you can easily notice, the last point is pretty ambiguous. In fact if you underestimate it may easily become an issue for your workflow. To avoid it, part of the efforts of the team during the Sprint Planning Meeting should be focused on the creation and the maintenance of the Definition of Done:

(sorry for the Spanglish, but that’s the way we like it :P)

Here in Thousand Gears we are a small team developing a game for the Nokia AppCampus and to keep things clear and controllable we choose to have short iterations (Sprints). Each Sprint lasts 1 week, normally. We use to track the speed of the team through burndown charts; doing so we noticed that the team is capable of estimate the 60% of real hours in the Sprint planning meeting, which is consistent with the average in literature.

Milestones

Each week we release a potentially shippable product, imagining we are going to participate to jams and competitions. At the end of each milestone (a set of one of more Sprints) we produce a new increment for our game. Our milestones are:

1. Pre-prototype: concept creation and implementation of a very basic system (even with objects and paper) showing the main loop

2. Prototype: establish technology and tools to develop a first basic release of the game. Imagine that you are going to participate to a Ludum Dare or something similar.

3. Demo: Create levels, art assets and implement features.

4. Alpha: Improve the content and the art assets with a basic bug-fix

5. Beta: final bug-fix

At the end of each milestone we run playtests. The first one (pre-prototype) is the only one internal, the goal is to motivate the team to the “let’s do it!”.

From the Prototype they are public, you can see our releases here and here.

What about design?

In general we do not believe in producing a huge amount of documentation; we prefer instead to create a GDD, where the acronym stands for Game Design Diary: each Sprint a new (and lightweight) chapter for the diary is written and shared with the team. In this way we can both add details to the original concept and maintain track of the history of the whole project. It will be totally transparent for every member of the team what is changed (and when) during the development, which is good for further analisys. Plus, it is easier to write down new stories starting from smaller documents.

Conclusions

In game development there is not any magic formula for success; the whole process is trial -> result -> learn. Scrum is not a method, it is a methodology: it is a philosophical thinking on research techniques more than an implementation of a logical-rational path through action. It happens that we should take some clear decision, so the best is to keep the things as simple as possible and measurable. The whole process is empirical, you have to study a lot about best practices and then apply them to your context and culture, in order to adapt them more to the people of the team.