BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Do We Need an Iteration Zero?

Do We Need an Iteration Zero?

Leia em Português

There are usually multiple things which need to be done before the start of a project. Teams usually use 'Iteration Zero' to put all necessary systems in place in order to start delivering business value in subsequent iterations. Is this the right way?

George Dinwiddie suggested that even though teams try to get all preliminary work done however, they soon realize that there is still a lot to be done in subsequent sprints. If they try to do a lot of preliminary work then, the infrastructure decisions, choice of technology and list of features defined in iteration zero would drive the project rather than the other way round.

George suggested that every iteration needs to produce working software.

Ask yourself, “what would it take to start delivering?” … Take that one thing, and slice it into thinner slices. Decide on the examples that represent acceptance of those slices. Some of the slices will have questions that can’t be answered. Put those aside for the moment. Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible. Estimate that as one team-iteration. (Estimates don’t have to be “right.” They’re just estimates.) Start building it.

According to George, this is the best way to start. The team should learn the necessary skills in technology and slowly build the development infrastructure while accomplishing real work.

Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits. Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project.

Likewise, Artem suggested that he would not prefer to have an iteration which does not demonstrate anything. Artem suggested that even though a major portion of the so called iteration zero might go in preliminary activities however he would still like to validate the core of the system end to end.

Alistair Cockburn mentioned,

I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented "Oh, that was Sprint Zero!" to get the peasants with the pickaxes away from his doorstep. ... and then others thought that was a great answer and started saying it, too. ... and then it became part of the culture.

Responding to a question about equating iteration zero with upfront planning, George mentioned that he cannot imagine getting to iteration zero without upfront planning. That would be a part of project chartering. However, most teams do not get into vision and goals in iteration zero. They rather spend their time in building a detailed backlog and creating the infrastructure.

On similar lines. Ken Schwaber had mentioned,

Sprint 0 has become a phrase misused to describe the planning that occurs prior to the first sprint ... and since planning creates artifacts that often change, it should be minimized prior to the first sprint, and then occur every sprint at the sprint review/sprint planning meeting (just in time planning).

Thus, there seems to be a general consensus that iteration zero could be best avoided, if possible. The key lies in adding business value right from the start. Does your team see a significant value in having iteration zero as compared to starting with business value and building infrastructure and deciding on technology stack along the way?

Rate this Article

Adoption
Style

BT