Featured Blog

Using SCRUM in indie game development

In game development there is not any magic formula for success; the whole process is trial -> result -> learn. SCRUM methodology fosters the learning and improve the responsibility of each member of the team.


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.


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.
  • clear goals
  • few controls
  • social game
  • short game sessions (average)


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.


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:


As a/an

I want to...

so that...



see the taxi going alone

I can focus on dodge and take passengers



see my winnings in the summary: rewards, kilometers

I will have the sensation of my mastery



encounter obstacles during my trip

I will have a clear challenge



use gestures to control my taxi cab

I can get the feeling of move it with my fingers



have a new track from the second time I play

I can have the feeling of variety in the game



have a vertical layout

I can use my phone with a single hand



choose whenever to carry a passenger or not

I can choose to run for money or for km


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:

  • To Do: tasks which are not taken from anyone

  • Doing: tasks which are in current development

  • Test: tasks completed which should be verified from something other from the team

  • Done: tasks that can be considered ended

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:


DoD 17/06/2014

(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.


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.


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.


Latest Jobs

IO Interactive

Hybrid (Malmö, Sweden)
Gameplay Director (Project Fantasy)

Arizona State University

Los Angeles, CA, USA
Assistant Professor of XR Technologies

IO Interactive

Hybrid (Copenhagen, Denmark)
Animation Tech Programmer

Purdue University

West Lafayette, IN, USA
Assistant Professor in Game Design and Development
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more