Sprint Zero: a myth, a habit or a useful idea?

A new team gets a new product. There is no repository, no build, no environments, no agreed Definition of Done, and the backlog is a first draft. Someone suggests a Sprint Zero, "just to get set up". Everyone nods, because it sounds sensible. Four weeks later the team has a long list of installed tools and nothing a user could try.

What the Guide says

The Guide has no Sprint Zero. It says all the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, the Sprint Review and the Sprint Retrospective, happens within Sprints. Every Sprint is expected to end with an Increment that is usable and meets the Definition of Done, and every Sprint has a Sprint Goal, which is the single objective for the Sprint.

A Sprint Zero fails each of these. It has no goal that a stakeholder cares about, it produces no Increment and it often skips the events. The Guide's end note is firm on the underlying point: leaving out elements covers up problems.

That said, the Guide does not forbid preparation. The first Sprint is allowed to be about getting started, as long as it is a Sprint, with a Sprint Goal and an Increment. Nothing in the framework stops a team from agreeing on a Definition of Done, setting up a repository, and building the thinnest possible slice in the same Sprint.

What the SBOK does

The SBOK® Guide takes a different structure. It places the Initiate phase before any Sprint: creating the project vision, identifying the Scrum Master and stakeholders, forming the Scrum team, developing epics, creating the Prioritized Product Backlog and conducting release planning. These processes are numbered 8.1 to 8.6 in the Fifth Edition. They happen before the iterative Sprints begin and include creating the Done Criteria and the release planning schedule.

So the SBOK has an explicit pre-Sprint phase, and it is part of the method. It is more like a short project initiation than a Sprint Zero. It involves the Product Owner, stakeholders and the team, and it produces specific outputs. The two sources therefore differ in structure while agreeing that preparation is needed.

A comparable idea outside Scrum is the discovery phase in government digital services. The GOV.UK Service Manual describes a phase in which the team understands the problem before building: users, constraints, opportunities and the value of solving it. It says not to start building the service during discovery, and notes that around four to eight weeks is typical but the purpose should decide how long it takes. That is closer to the SBOK's initiate phase than to a Sprint Zero.

Why teams reach for it

The reasons are understandable.

• Technical set-up. Repositories, environments, build pipelines and tools take real time.
• Team formation. New people need to meet, agree a working method and set a Definition of Done.
• Backlog preparation. The Product Owner needs a first set of items ordered and refined.
• Architecture. Some early decisions are hard to change.
• Pressure. A manager wants a plan before anything else.

Each need is valid. What goes wrong is the container. A separate Sprint Zero often runs long, since there is no Sprint Goal to stop it. It produces no feedback, so assumptions go untested. And it invites a Sprint One, Two and Three that all look like Sprint Zero, with "technical Sprints" and "hardening Sprints" that delay value.

A better approach: a thin first slice

This is an illustrative case. A team is building an online booking tool. Rather than a Sprint Zero, the Product Owner and team agree a first Sprint Goal: a person can create an account and book one fixed appointment slot, end to end, on a test environment.

To meet it, the team must do the set-up, because the goal needs a repository, a pipeline, an environment and a working path through the system. The set-up is real, driven by the goal, and only as large as the goal needs. The Increment is ugly and tiny, and it works. At the Review, a stakeholder clicks through it and asks for the confirmation email to say the practitioner's name. The Definition of Done is written in the first planning session, short at first, and tightened in the Retrospective.

The team ends the first Sprint with less set-up than a Sprint Zero would have produced, and with something to inspect. A common name for this kind of slice is a walking skeleton. It is not in either source and is a practitioner idea.

When a short preparation is reasonable

Sometimes a real pre-Sprint period is the honest choice: when a team has not yet been formed, when funding depends on a vision and plan, or when the problem itself is unclear. In those cases do three things.

1. Call it what it is. "Discovery" or "initiation" is more accurate than Sprint Zero, and sets expectations about what it will deliver.
2. Timebox it with an outcome. A fixed duration and a stated output, such as a vision, a first ordered backlog and a Definition of Done, stop it from drifting. The SBOK's initiate processes list those outputs.
3. Keep it short. The longer it runs, the more it resembles waterfall's requirements phase.

A note on hardening and stabilisation Sprints

Sprint Zero has relatives at the other end of a project: the hardening Sprint, the stabilisation Sprint, the release Sprint. They share the same logic. Work that should have met the Definition of Done is pushed into a later period of its own. The Guide's rule that quality does not decrease during the Sprint, and that an item that does not meet the Definition of Done returns to the Product Backlog, leaves no room for them. If a team finds it needs one, the signal is that its Definition of Done is thinner than the work requires, and the repair is to tighten the definition and change the practices, not to add a Sprint.

Common mistakes

• Treating it as a free Sprint. No goal and no Increment means no inspection.
• Skipping the events. Even setup work benefits from a Daily Scrum and a Retrospective.
• Letting Sprint Zero repeat. Sprint Zero, Sprint Zero-and-a-half and then "stabilisation" Sprints are the same pattern.
• Putting only technical work in it. The Product Owner's preparation matters as much.
• Refusing to do any preparation. Starting with no repository or agreed standard wastes the first Sprint too.

How to practise it

For your next new product, write a Sprint Goal for the first Sprint that needs the set-up work to be done, and check that a stakeholder could see the result. In the simulator the first phase is spent on the vision, team and backlog before the Sprints start, so you can see the SBOK's approach in practice.