Sprint Zero

Definition

Sprint Zero is the informal name for the first (or preparatory) sprint on a new team or project, in which the team assembles the infrastructure needed to actually deliver. It is controversial in the Scrum community — purists correctly point out that Scrum recognises only value-producing sprints — but it is an honest name for a real activity that every new team performs, whether they call it that or not. The alternative is pretending Sprint 1 is a delivery sprint when it is really full of environment setup, and then wondering why velocity looks weird for the first month.

What Actually Happens in Sprint Zero

• Environment setup — repositories, CI pipelines, deployment infrastructure, monitoring.
• Initial backlog population — enough refined stories to run the first delivery sprint.
• Definition of Ready and Done agreed.
• Team norms — meeting cadence, working hours, communication channels, on-call arrangements.
• Tooling — issue tracker, chat, documentation platform, access provisioned.
• Architecture spike or walking skeleton — the thinnest possible end-to-end path proven.
• Stakeholder mapping and initial governance touchpoints agreed.

Why It Exists

A team that starts Sprint 1 without an environment, a refined backlog, or agreed working norms produces almost nothing in Sprint 1 and burns most of Sprint 2 on the same setup. Naming that reality Sprint Zero and time-boxing it (typically one to two weeks) forces the team to complete the setup deliberately, produces a walking skeleton at the end, and lets Sprint 1 begin with the team pointing in the same direction.

Real-World Example

A team I coached at a financial services firm was mid-way through their fourth sprint. Their velocity was erratic (11, 4, 19, 6 story points), stand-ups were long, and no one was quite sure what "done" meant. We paused for a one-week Sprint Zero — retrospectively, four sprints too late. We wrote the Definition of Done, added CI to the repo (there wasn't any), set up a staging environment (deploys had been manual), and refined 15 stories to Ready. Velocity from that point stabilised at 22 ± 3 for the next quarter. The retrospective on that Sprint Zero was blunt: they wished they had done it before Sprint 1.

Practical Lessons Learned

• Time-box it aggressively. Sprint Zero can eat weeks if you let it; one to two weeks is normal, longer is a red flag.
• Produce something visible. A walking skeleton — one end-to-end path deployed to a real environment — is the best output.
• Don't skip the human parts. Working agreements, communication norms, and DoR/DoD are as important as the pipeline.
• Refine enough backlog for two sprints, not the whole product. The rest is progressive elaboration.
• Don't call it Sprint Zero and then produce nothing. Zero sprints are for setup, not for hiding.

Common Mistakes

• Using Sprint Zero as a licence to design the entire architecture up front.
• Skipping it and hoping Sprint 1 will absorb the setup — it won't, it will just look like a bad sprint.
• Producing no walking skeleton — a sprint of documents and diagrams with nothing running.
• Refining stories for the whole roadmap instead of just the first delivery sprints.
• Not agreeing DoR and DoD, leaving them to be improvised story by story.
• Letting Sprint Zero become Sprint Zero-Point-Five, Zero-Point-Six, and so on.
• Excluding testers and operations from Sprint Zero, then bolting them on later.

Expert Tips

• Produce a walking skeleton by the end. If nothing runs end-to-end, the sprint failed.
• Include everyone who will be in delivery sprints. Ops, security, and QA belong from day one.
• Write DoR and DoD collaboratively. Documents handed down are ignored; documents authored jointly are followed.
• Set a stretch goal of "first story delivered." Even one small story shipped in Sprint Zero confirms the pipeline works.
• Retrospect on Sprint Zero honestly. The lessons apply to every subsequent sprint.

Key Takeaways

• Sprint Zero is a pragmatic acknowledgement that setup work exists and deserves its own time-box.
• The output is a walking skeleton, agreed norms, and a refined backlog — not a design document.
• Time-box to one or two weeks; longer indicates scope creep into up-front design.
• Skipping it doesn't remove the work; it just distributes it across erratic early sprints.
• Include the whole team, including ops and QA, from the beginning.

Related Concepts

Interlocks with Definition of Ready, Definition of Done, Iteration Planning, Velocity, and Progressive Elaboration. Templates at PMMilestone.org.