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? How do we get a team writing code and delivering value as quickly as possible? And, how quick can that be?

Read no further if your team is ready to write code as soon as it is assembled. If that's not the case, then continue reading about the Sprint Zero concept, which many coaches have used (and are using) successfully to get a team up and running quickly.

The idea is simple: take an initial sprint (called Sprint Zero, Iteration Zero, Inception Sprint, etc) that has the following three goals:

1. Get some quality items on the Product Backlog,
2. Provide a minimal environment that enables the writing of quality code, and
3. Write a piece of real code, nomatter how small.

And, of course, make this Sprint Zero as short as possible. In my experience, this sprint can be as short as one week, which is what I recommend. I recommend one week in order to apply pressure on the team to achieve the goals in as quick and efficient a way as possible -- I don't want the team to do any gold-plating or unnecessary work in order to get to that first real code. Of course, there is continued work on environment and the Product Backlog in future sprints, we don't delude ourselves that we're finished in Sprint Zero. In fact, we don't even delude ourselves that we've achieved the 80% solution, or even the 50% solution. We're just getting started... that's the point of Sprint Zero. Get started, but do real stuff as you start and ramp up.

So, what do we actually do in Sprint Zero? Well, we have an initial Sprint Backlog (even if it's just stickies on a wall) for Sprint Zero, that has just the same three things on it:

• Get some quality items on the Product Backlog,
• Provide a minimal environment that enables the writing of quality code, and
• Write a piece of real code, nomatter how small.

Now the conversation that we call the Sprint Planning Meeting starts, and we elaborate each of these three items to add acceptance criteria, tasks, and so on. This conversation is what is really important, and here's the way it goes...

For the first item, I could express it in Connextra story form as "As a [developer] I want [good stories in the backlog] so that [I will be confident that I'm delivering value when I code]." This statement points out why we want to do some up-front analysis (oops, dirty words, my bad...) in order to figure out what we're actually trying to build. The acceptance criteria (along with some notes of how to accomplish them) for this story could be something like this:

1. Add at least ten good stories to the Product Backlog that have been validated by our stakeholders. We suggest having a one-day meeting with them to figure out waht these stories are - and epics are ok for now...
2. For at least one of these stories, make sure it is small enough, and well enough defined, that we can develop it in one day once our minimal environment is in place. You will need to work with the developers to do this. In other words, split off at least one good story from one of the epics...

The second item is a little easier, and is simply expressed as "As [developers] we want [to be able to write quality code] so that [we can produce value for our users]." The conversation about this story centers on how much environment is enough, and the acceptance criteria might be something like:

1. Configure everybody's machines
2. Set up a build box
3. Get the database server set up
4. Get ScrumWorks up and running

Finally, the third item becomes "As the [product owner] I want [some real code written] so that [I have something to brag about at the Sprint Review]." The idea is that when we have a real story from the analysis, and a good enough environment, we will use that environment do do the story -- pretty simple, really.

So, what does the Sprint Zero actually look like? Well, it's a week long, and we spend half a day planning, and will spend half a day with the review and retrospective at the end. This leaves four days for actual work. In two roughly parallel tracks (some team members will be shared), we'll spend two days setting up the environments, and two days getting the Product Backlog together. Then, we choose the story to actually implement and get it done. This takes a day or so, leaving us almost a day of float. It seems like a workable plan to me...

Anyway, I hope that this discussion of the Sprint Zero concept helps you think about how to start a project quickly, and not let the beginning drag on forever.

Thanks, Dan ;-)
dan@danube.com