Scrum first steps

Why Scrum?

 * It is lightweight.
 * Gives freedom and control to the developers.
 * Has been demonstrated to work with remote teams.
 * Fits in nicely with Farsides' current Redmine workflow.

Why User Stories?

 * They're simple to write, and simple to read.
 * They work well as a complement to mockups.
 * They're perfect as a product backlog for sprints.

For a concise but good explanation, see the wikipedia article.

The Whole Shebang
This section will describe the whole process from beginning to end, chronologically. In other words, things should happen in the order they appear here.

1. Writing the stories
The first thing to do is to write the actual stories. They should be very simple, with as few technical terms as possible, so as to be understandable by anybody. The preferred format is something informal like the following:

The player can pick a single card from a set of six.

Now, imagine that at this point there is a mockup (which provides essential information), but there is no code whatsoever. How will this story guide the developers? It's simple: for this story to be completed, the developers need to deliver a fully functional prototype that implements exactly what the story says, regardless of the technical hurdles. Because of this, the following are essential:


 * The stories must be simple and straight to the point, in such a way that it is possible to use them as a reference both for development and for later validation.
 * They cannot be vague or define an objetive that is too broad, otherwise they will not fit into a single sprint.

Writing the stories is a responsibility of the Product Manager, but it is always best to write a good chunk of the stories in a brainstorming session involving as many members of the team as possible! Write as many as you can, ideally covering all foreseeable features: they can always be thrown out or rewritten later, but it is better to have an idea of where you intend to get.

Stories should be written in a new tracker in Redmine, called "Story".

2. Ordering stories
Once an appropriate number of stories has been written, it is time to prioritize them. Since at this point no one knows how long it will actually take to finish them all and deliver the envisioned product, the Product Manager must organize them in order of most important at the top, to least important at the bottom. For example, the first story might read like this:

The player can log in using his email.

This is at the top because without a way to identify the player, the game itself cannot work! There will be other stories in the middle, but a story such as the following may be at the very bottom:

The player can invite his friends using Google+.

After all, Google+ sounds promising, but no one knows if and when it'll catch on (especially since it is currently a social network that invites no one in), and as such, is of very little immediate importance.

Stories should be ordered using the priority field on Redmine.

3. Sizing stories
The previous two tasks do not require the development team to be present (although it is nice to have them contribute, too). But for sizing the stories, they are essential. Why? Because the size of the story is only useful for one thing: estimating how long it'll take to finish them, without actually trying to come up with a number of hours for each one (a relatively labor-intensive proposition in and of itself).

The recommended way to size a story is with "story points" (lovingly called "bananas"), which have no dimension or any direct relation with time at all: they only represent a story's size in relation to the others on the list. So, for instance, the following story may be a "1", because it is very easy to implement:

The author can always see the card he chose initially.

But the next one may be an "8", because it is roughly 8 times harder to implement (or takes 8 times longer) than the previous one:

All players can chat with each other in realtime during the game.

Sometimes a story will be judged to have too many points to be practical, let's say, "21". In this case, it is referred to as an "epic" and should be broken down into smaller pieces.

There is a very fun way to decide how large each story is with the team: poker planning. For a full description of the method, see the wikipedia entry. A free online poker planning solution also exists.

A custom field will be created on Redmine to define each story's size.

4. Planning a sprint
Planning an actual sprint is a two-step process itself. First, a sufficient number of stories must be chosen for the sprint, and then those stories must be broken down into tasks by the team itself.

Chosing stories at this point is simple, if you know your team's speed in "bananas". For instance, if the team can take 60 bananas for 2-week sprints, going from top to bottom select stories until that number is reached.

For you first sprint is not an easy task, because at this point you do not know how many "bananas" your team can handle per sprint. In this case, or just as an alternative to the whole concept of bananas/story points, you can calculate the theoretical available volume of paid work per expertise (code/art/GD/etc) during the sprint. For instance, if 3 people work full time on code, during 2 weeks => 3x10 days * 8 hours = 240 hours of work available for coding. The sum of each sprint's task times should not exceed this.

After chosing the stories, the development team must meet to define individual tasks to be created in the "Task" tracker. Each task will be created as a subtask to a story, and stories will typically have several tasks, each one specified in as much technical detail as needed, time estimated by the team, and finally self-assigned by a willing developer. It is important to note that the task assignee is in charge of coordinating with related tasks to ensure timely delivery (with help from the Scrum Master). This overhead should therefore be taken into account when the duration of the task is estimated.

A new version should be created in Redmine for this sprint, and all tasks and stories should be targetted at it.

5. Ready, set, go!

 * 2 weeks duration
 * daily scrum meeting each day from monday to friday (see this page)

6. Sprint review
To conclude, story points serve as a big rough estimation to decide what to put in a sprint, according to the team velocity. But once one sprint is over, it is useful to double-confirm what can be done during the next sprints, by comparing the amount of available workhours to the estimated time in hours of tasks.

Next steps for scrum implementation
Once these first steps are working, we can see how to add incrementally add some other scrum features that can improve the pipeline:


 * Burn down chart (Jo suggests http://www.redmine.org/projects/redmine/wiki/PluginCharts)
 * Task board