Reasoning for zero iteration in scrum

Greetings, habrovchane!

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, are interesting for those who are interested in this direction.
In this article, I decided to talk about zero iteration in Scrum, its use among the masses, and also to try to determine whether zero iteration is part of true-Scrum or a feature of dark Scrum-batov, which acquired its name to please Scrum-branding.

I often meet teams that practice using the “Zero Sprint” in order to carry out the preparatory work: to bring their development integration server, continuous integration server to a normal state, to prepare the team for the start of a new phase of work, etc. Why Did they decide that this is part of Scrum? How useful is it at all?
I thought that on this issue it would be best to turn to the statements of persons known in Agile circles.

Jeff McKenna says:

This term is often used by newly formed teams, or by those who are new to Scrum. Ordering the initial backlog, bringing workplaces and machines for the build and autotesting to work, preparing all the tools, perhaps a little training, and a little more work to make sure that it all works. ... This is not the “official” Scrum, But this is a common case, which is quite common. We expect the teams to 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 (it is called its initialization, zero sprint or zero iteration), and we give it simple goals:

• Get a number of quality items 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 Vaughan believes that the zero sprint is better to use as a spike:

The team must make 3 results by the end of this iteration.

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

Peter Stevens , Agile Coach from Switzerland, uses a zero sprint to evaluate the most important features (not all), to agree on a common opinion in the definition of “what it means to do”, to restore / increase customer confidence. Like many others, he advises to make the length of this sprint shorter than the others, normal in length for the team sprints.
So is this Scrum? We get an iteration of a completely different length than the usual sprint length for the team, and the result of the sprint is not a potentially sales-ready product. Or maybe it is so useful that you can close your eyes to such inconsistencies?
')
Many teams have a lot of things to do before starting a project / release.
George Dinviddi believes that even if the teams are trying to do all the preliminary work - there is always a lot of unfinished things to do in the upcoming sprints. And we can also add: “We welcome change!”. So, decisions on infrastructure, choice of technologies, 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 exit.

Ask yourself what you need to start the delivery of the 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. At the moment, set these pieces aside. Choose one central piece that goes through the whole concept from beginning to end, or is close to it. Rate it as one iteration for the team. Estimates should not be "correct", they just have to be! Start developing this product!

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

Yes, the development infrastructure will still have to be completed. There should be no particular rush to finish it. Just continue to improve it in such a way as to increase the amount of work done. Yes, technical skills still need to be improved. It should always be. Just keep experimenting and expanding your boundaries. Yes, there will still be features that need to be added to the backlog, priotized, divided into stori and re-prioritized. This should go on forever.

I also would not recommend to carry out iterations that show nothing. Although most of the zero iteration can take place in preliminary activities, 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.

Alistair Cowburn on this issue tighter:

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

Is it worth equating the sprint zero to pre-planning (upfront planning)? Some really hard to imagine a zero sprint without prior planning. Representing that this is part of a project chartering. But many teams, however, do not discuss the goals and vision of the project during the zero iteration. They more often spend time creating backlog and infrastructure.

Ken Schwaber on this subject says:

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

It turns out that the general opinion of the ajile luminaries on the issue of the zero sprint is more likely to agree that this is not quite a dear thing for scrum, and it is better to avoid it if possible. And the key point is adding business value right from the start. Does your team see a significant plus in zero iteration instead of immediately starting to produce a 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 - whether it all smacks of a situation when the “preparatory work” ends neither after the zero iteration, nor after the first one, and this will prevent the team from moving forward in full swing and it doesn’t smell something 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 producing a significant product increment after doing some preliminary actions, but I still have a list of actions that we can try to use in order to avoid holding a Zero Sprint.
What I naturally write about in the next article.