Development Cycle

=Abstract=

The idea is to implement scrum in our projects, adapting it to two of our main needs :
 * decentralized : we need online tools that simulate all the scrum process that is usually implemented within the physical space where the team works
 * video games : this requires to tweak a little bit the scrum process, mostly because of the heavy dependencies between teams in video games

=Methodology=

You can also check http://en.wikipedia.org/wiki/Scrum_%28development%29

Introduction
Theoretical objectives, in no particular order : improve reactivity and adaptation to change, reduce the chain of command, write less documents, base relations on customer collaboration rather than contract negociation, plan all of the time and not only at the beginning.

Description
The core element of scrum is small iterations called sprints.

All the possible features of the game are stored in a backlog, where they are called user stories. These stories are prioritized, and cut into elementary tasks and time estimated. At each beginning of sprint, a list of user stories, to be finished during the sprint, is selected from the backlog, based on the previous pace of development. At the end of the sprint, the pace of development is measured again and updated, and so on.

Sprint

 * typically 1 to 2 weeks
 * The delivery at the end of the sprint must be playtestable
 * useful to define one release every 4 or five sprints (a release = measurable impact for the final player)

Meetings

 * every day, 5-10mn scrum meeting (each member of the team says : what was done yesterday, what is going to be done today, anything blocking. Should be as short as possible)
 * each beginning of sprint : the team takes the user stories with highest priorities in the backlog, cut them into tasks (each task must be < one day) and estimate their time, measures this way the time taken by each user stories (for instance using poker planning), and decide how many can fit in the sprint, according to the pace of development of the team until then. The time unit for measuring the length of tasks can be the 'ideal hour'
 * each end of sprint, a sprint review that includes : post mortem, updated measure of the pace of development, updated backlog
 * make sure the sprint doesn't become a waterfall =>important to parallelize all tasks : conception/production/integration/test

Tools

 * task board, with various columns (not started/in progress/pending/completed). And for every task of every user story, a card is created, that is moved across the columns according to the progress of the work
 * burndown chart : X for the time remaining before end of sprint, Y for the quantity of work remaining (remaining cards multiplied by duration of each card). Gives the average number of 'ideal hours' (the time unit used on the cards) done each day by the team and therefore the dev pace.

User story

 * must show benefit for the player. So it should follow the following structure : "As a, I want [so that - this part is optional]"
 * When a user story is too big to fit in a sprint, it's called an epic. For instance, 'As a player, I want to be able to manage a department of humanity project'. Too big. Then the epic is kept in the backlog, prioritized, and cut into smaller pieces (user stories).
 * the epic is cut into user stories only when its priority becomes high. The same way a user story is cut into tasks only when it's a candidate for the next sprint.
 * When the duration of a user story is unknown (no consensus within the team), it's always possible to create a small user story which goal will be to estimate the duration of the user story

Team

 * size = 7-10 people. Beyond, implement a scrum of scrum
 * roles - very shortly :
 * scrum master : in charge of organizing the scrum, of ensuring the team has the ownership
 * product owner : has the A on the content of the project (more specifically the backlog and the priorities of the user stories)
 * same person can have both roles

Scrum adapted to video games

 * Three separate phases in vg production : conception/pre-prod/prod. Sprints must be adapted to each phase. For instance, sprints in conception tend to multiply various prototypes in order to create knowledge, and in pre-prod, the main function of sprints is to setup the pipeline of prod and address the various risks by creating knowledge before entering in production.
 * Strong dependencies between jobs (ex of creating a map : concept -> level design -> art -> audio -> polish).
 * The sprint organization needs to be adapted accordingly, so that when one task is finished by a team, the other team is available to do its part on the same asset.
 * One of the way to adapt is to add to the task board a set of columns that describe the status of an asset (map, character, etc) and each column represents a team of the pipeline (design/prog/art/etc).
 * Each user story can be owned by a game designer, where he does not write complete specifications but exchanges extensively with the team and refines the design across the sprint.