Danube - Sprint Zero - Comments

get the "pre-game" into the game

MichaelJames — Sun, 10 Jun 2007 14:00:00 -0500

Once you have a team, there is no reason to procrastinate Sprinting with a pre-game phase.

Negotiate an extremely thin vertical slice of functionality that still has some business value, and call that your selected backlog for the first Sprint. It doesn't have to be the most important thing, if you don't know what that is yet. It could be something subject to change, like everything else.

Acknowledge that most of the work will be research, getting to know each other, set up activities, and the other things you're calling "pre-game". Do not expect a high velocity for this first Sprint (whether you number it zero or one).

Optionally, create first-class Product Backlog Items (without business value) for the "pre-game" activities. Just make sure at least one of them in each Sprint has business value. This is necessary as a reality check on the non-business value work, and to start feedback-driving the Product Backlog ASAP. The Sprint Review Meeting is what drives the Product Backlog, not all the early speculative analysis done in a vacuum.

The sooner you get the team used to working with each other inside fixed iterations the sooner they'll work their way up the "forming/storming/norming/performing" ladder. This is why Scrum coaches generally oppose varying the Sprint duration: We've found the team gets into a rhythm, facilitating flow.

--mj
Michael James
Software Process Mentor

I used to name the pre-game phase as Sprint Zero

twlodarek — Sun, 10 Jun 2007 08:37:58 -0500

More general question: how do you actually do the pre-game - the time when project starts, backlog is filled with preliminary items, team has the chance to do some reasearch, setup and configuration work etc.

Cheers,

Why The Name?

Dan Rawsthorne — Tue, 22 May 2007 01:19:04 -0500

I think that the reason the name and length of Sprint Zero are distinctive is purely emotional. Many teams have heard that every sprint must provide "potentially releasable" product, and what we're doing here doesn't seem to meet that standard.

Rather than spend time educating them about what "potentially releasable" actually means, I just say "right, but this isn't a real sprint. It's Sprint Zero..." and just get on with things. Once the team is actually moving it becomes easier to discuss the facts of life with them...

Dan Rawsthorne, PhD, CST
Transformation Coach
http://www.danube.com

Agreed

VictorSzalvay — Mon, 21 May 2007 08:38:51 -0500

Why call this Sprint Zero? Isn't this just Sprint one? Why the odd the length of time?

I'd much rather start a team out with a normal sprint duration to get them into the rhythm of delivering product each and every sprint. They would still learn the same lessons, imo.

-- Victor Szalvay

Sprint One

MichaelJames — Mon, 21 May 2007 06:58:00 -0500

Many of us also like doing a Sprint One, with the following three goals:

Get some quality items on the Product Backlog,
Provide a minimal environment that enables the writing of quality code, and
Write (and test) a piece of real code, no matter how small.

After that, if there's time, we do a Sprint Two, with these goals:

Get some quality items on the Product Backlog,
etc.

It turns out all Scrum Sprints involve analysis, design, infrastructure, process improvement, implementation, test, and validation, in varying proportions.

--mj

Michael James
Software Process Consultant
http://www.danube.com

SprintZero

Christopher Elisan — Mon, 21 May 2007 03:31:38 -0500

I implemented Sprint Zero with my team last January with an 8 days Sprint and it worked really well for my team. The team was able to produce a working software in a very short period of time. The management was impressed.

The people I have in my team when I did the Sprint Zero has no previous experience with Scrum. So it was an immersion experience for them.

We actually called it Sprint Zero back then. So this article was like a validation that what we did before is actually working.

Sprint Zero

Dan Rawsthorne — Sun, 20 May 2007 00:25:23 -0500

Agile development is all about delivering value early and often, in order to get and incorporate feedback as soon as possible. Many of the organizations I coach are convinced that it will take months before they can write any code that produces value. Is this a reasonable fear? How do we get past this fear?