Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 2, 2014
arrowPress Releases
October 2, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Using SCRUM in indie game development
by Paolo Gambardella on 07/29/14 02:46:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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:
  • 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.

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:

 

As a/an

I want to...

so that...

KPI

newbie

see the taxi going alone

I can focus on dodge and take passengers

engagement

casual

see my winnings in the summary: rewards, kilometers

I will have the sensation of my mastery

engagement

casual

encounter obstacles during my trip

I will have a clear challenge

engagement

newbie

use gestures to control my taxi cab

I can get the feeling of move it with my fingers

engagement

newbie

have a new track from the second time I play

I can have the feeling of variety in the game

quality

casual

have a vertical layout

I can use my phone with a single hand

engagement

newbie

choose whenever to carry a passenger or not

I can choose to run for money or for km

engagement

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.

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.

 
 

Related Jobs

Trendy Entertainment
Trendy Entertainment — Gainesville, Florida, United States
[10.01.14]

Development Director
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.01.14]

Senior Game Designer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.01.14]

Producer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.01.14]

Senior Tools Engineer - Infinity Ward






Comments



none
 
Comment: