At the beginning of a new piece of work, some teams will choose to run a Sprint that focuses purely on setup first. These can include anything from the Scrum Board through to source code repositories, Wikis to staging, and even production deployment pipelines.

This Sprint is often called Sprint Zero, although it is not officially recognized or sanctioned by the Scrum guide. Sprint Zero does deviate from the Agile Manifesto in that it delivers little or no working software at the end of it.

It's also not uncommon for teams to try to expand the Sprint Zero well beyond the usual iteration length—5 to 6 weeks isn't uncommon. This is a sign that the transition from a Waterfall-style delivery to an incremental one is too difficult for some to make.

As a coach with experience, this feels like procrastination. Sprint Zeroes can be used by teams as an excuse not to transition to an Agile approach, but instead stay comfortable with what they know. In this case, procrastination is a form of applied anxiety.

The one thing that I can honestly say is that if we always stick with what we know, we may never discover if the alternative is better.

It's important that we experiment and are not afraid to fail. Scrum is an empirical process, so 'failing' is more of a discovery of what works and what doesn't! 

Instead of using Sprint Zero, treat the tooling and infrastructure that you need to set up just as you would each feature: deliver it incrementally. You can do this either as part of each feature, by looking for User Story candidates in which you can include infrastructure setup, or by defining small User Stories that can be interwoven into your Product Backlog alongside feature delivery.

For instance, the first User Story will likely include setting up the source code repository and creating an initial deployment pipeline to a staging environment. Subsequent User Stories will likely include logging and enhancing the deployment pipeline to point to a production environment, and so on.

If you treat your infrastructure setup as you do your feature delivery, you can maintain maximum flexibility by delivering just enough to move forward. To avoid making assumptions, we need to solve the problems we have now, not the problems we don't have yet.