Reasoning about Zero Iteration in Scrum

Greetings, Khabrovites!

Today I decided to write my first article on Habr (so do not judge strictly).
In this, as in most of the following articles from me, I will talk about Agile. Scrum and some moments from this series, in my opinion, which are interesting to those who are fond of this direction.
In this article, I decided to talk about zero iteration in Scrum, its use in the masses, and also try to determine whether zero iteration is part of true-Scrum or a feature of dark Scrum bats, which acquired its name in favor of Scrum branding.

I often meet teams that practice using Zero Sprint in order to carry out preparatory work: bring their Product Backlog and development infrastructure (continuous integration server) to a normal state, to prepare the team for the beginning of a new phase of work, etc. Why did they decide that it was part of Scrum? How useful is this?
I thought that on this issue it would be best to turn to the statements of famous personalities in Agile circles.

Jeff McKenna says:

This term is often used by newly formed teams, or those who are new to Scrum. Organizing the initial backlog, bringing jobs and machines for build and auto-testing to working order, preparing all the tools, maybe a little training, and a little more work to make sure that it all works. ... This is not an “official” Scrum, But this is a common case, which is quite common. We expect that the teams will be fully prepared (after zero iteration) to attack the real work!

Den Rausorn described the zero iteration as follows:

The idea is simple: we take the initial sprint (they call it initialization, zero sprint or zero iteration), and we set simple goals for it:

• Get as a result a number of quality elements in the product backlog
• Provide a minimal development environment that provides the ability to write quality code,
• Write a minimal working code, and it doesn’t matter how small

Mark Wowna believes that a zero sprint is best used as a spike:

The team should do 3 results by the end of this iteration

• List of all rated and prioritized features / stories »
• Release plan in which all features / stories are placed in the necessary iteration / sprint
• The application architecture should be created, at least at a high level, that is, it should be clear how these features will be implemented.

Peter Stevens , an agile coach from Switzerland, uses a zero sprint to evaluate the most important features (not all), agree on the definition of “what does it mean”, restore / increase customer confidence. Like many others, he advises making the length of this sprint shorter than others, normal in length for the sprint team.
So is it Scrum? We get an iteration of a completely different length than the usual sprint length for the team, and the sprint result is not at all a potentially ready-for-sale product. Or maybe it is so useful that you can close your eyes to such inconsistencies?

Many teams have many things to do before starting a project / release.
George Dinwiddybelieves that even if teams try to do all the preliminary work, there is always a lot of unfinished that remains to be completed in the upcoming sprints. And we can also add: “We welcome change!”. This means that infrastructure decisions, technology choices, and a list of features defined in the zero iteration will control the process, and not vice versa. But each iteration should receive a working product at the output.

Ask yourself what it takes to start delivering a product? Take it and cut it into small slices. Come up with examples that will show well that these slices are working. Some pieces will have unanswered questions. Set these pieces aside for the moment. Choose one central piece that runs through the whole concept from beginning to end, or close to it. Rate it as one iteration for the team. Evaluations do not have to be “right”, they just have to be! Start developing this product!

According to George, this is the best way to get started. The team must learn the necessary skills in technology, and then, slowly begin to build the development infrastructure until they finish the real work.

Yes, the development infrastructure will still have to be completed. There should not be much haste to complete this. Just keep improving it in such a way as to increase the amount of work done. Yes, technical skills still need to be improved. It always should be. Just keep experimenting and expand your boundaries. Yes, there will still be features that will need to be added to the backlog, prioritized, divided into stories and prioritized again. This must go on forever.

I would also not recommend iterations that show nothing. Although, most of the zero iteration can take place in preliminary events, however, I would still like to be able to validate the "core" of the system from beginning to end already at this stage, no matter how small it is.

Alistar Cowbern is tougher on this issue:

I am tormented by vague doubts that someone is putting pressure on your use of scrum as a team when you do something at the very beginning that does not give an obvious business value. And this “someone” invented “O. this is sprint zero! ”so that the peasants with pickaxes would leave his threshold ... And then, others, thinking that this was an excellent answer, repeated it again and again. And then it became part of the culture.

Should sprint zero be equated to upfront planning? It is really difficult for some to imagine a zero sprint without prior planning. Imagining that this is part of a project charter. But many teams, however, do not discuss the goals and vision of the project during the zero iteration. They often spend time creating backlogs and infrastructure.

Ken Schwaber on this subject says:

The phrase "Sprint Zero" was created to describe the planning that occurs before the start of the first sprint. And since planning creates artifacts that later change frequently, it should be minimized at this stage, and then every sprint should take place during sprint review / sprint planning

It turns out that the general opinion of the Agile luminaries on the issue of zero sprint is more likely to agree that this is not quite a thing for Scrum, and it is better to avoid it whenever possible. And the key is to add business value right from the start. Does your team see a significant plus in carrying out a zero iteration instead of immediately starting to produce business value, gradually building up the infrastructure along the way and making decisions about the technological stack?
If he sees, then you need to answer the question for yourself - does this all smell like a situation where the "preparatory work" does not end after either zero iteration or after the first, and this will prevent the team from moving forward in full swing, and doesn’t it smell like some team dysfunction? If the answer is no, maybe this is your way.

Although in some cases I may be wrong. For example, I forgot to mention the ease with which some teams can start to make a significant increment of a product after some preliminary steps, but still I already have a list of actions that we can try to use in order to avoid Zero Sprint.
What I will naturally write about in the next article.