Hi,
Here is a long mail to start the discussion on how we can use scrum in
our project.
For those of you who don't want to read everything, here's the abstract.
* The idea is to implement scrum in our projects, adapting it to two
of our main needs :
o decentralized : we need online tools that simulate all the
scrum process that is usually implemented within the
physical space where the team works
o video games : this requires to tweak a little bit the scrum
process, mostly because of the heavy dependencies between
teams in video games
* I found an open source online scrum tool that might fulfill part
of our needs, called Agile42
(http://www.agile42.com/cms/pages/agilo/).
* Suggested next step : anyone interested could test it (Xav I have
questions on installation for you at the end of the mail), and
then we discuss during our next friday meeting how we want to
start using it
Now, if you want to read more about Scrum (not a theoretical approach
but a description of how i used it myself), here it is.
Tell me if you want more details on some aspects (you can also check
http://en.wikipedia.org/wiki/Scrum_%28development%29) :
* Scrum introduction :
o 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.
o Description :
+ Overview :
# 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
# 2 tools to track progress of tasks :
* 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 <user
role>, I want <goal> [so that <reason> - 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
o 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
o Scrum adapted to video games.
+ Two main elements to be taken into account
# 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.
+ Scrum works quite well in video games. For instance a
large part of Ubisoft studios use it - I personally
used it the three years I spent over there.
* what we need with the online tool we'll use in order to start a
simple scrum :
o must have :
+ usual task tracker functionalities (status, users with
roles, etc)
+ user stories with priority level, and breakable into tasks
+ backlog to range the user stories and sprints where
the tasks are listed
+ task board for the follow-up of the sprint
o nice to have :
+ tools to help measure the pace of development (like
burndown chart)
+ adaptation to video games (specific roles, specific
task board for instance)
* Choice of tool
o I had a look at pivotal tracker which seems like a good
scrum tool. But it's not open source.
o So I looked for open source tools. I did not see anyone that
seemed as good as pivotal, but there is one which seems to
answer our basic needs, it's called Agile42
(http://www.agile42.com/cms/pages/agilo/). I haven't
completely tried it but I think it's worth giving it a shot.
+ I think that to have the task board available, we need
to purchase the pro version. We can start without it
and buy it later if we like the tool.
+ Even if it's not the perfect tool, i think it's worth
trying it because we will then learn more about scrum
and about our needs, and with this knowledge it'll be
easier to find another tool if needed.
+ Once you have access to the tool, you can use
Help->Process Overview to understand how to start
using it.
* conclusion and next steps :
o I suggest that the ones interested tests the tool, and then
we could discuss how to start using it during our next
friday meeting.
o Xav -> Installation of agile42 : I installed it locally for
now. For anyone here to be able to test it together, how
should we proceed - should we install it on our live server
? Can you help me on that part ?
_______________________________________________
Farsides mailing list - [email protected]
Wiki: http://farsides.com/
List: http://farsides.com/ml/
Forum: http://farsides.com/forum/
Ideas: http://farsides.com/ideas/
Chat: http://farsides.com/chat/
