Sprint Zero: When It's Worth It and When It's Waste
Sprint Zero is a preparation sprint before you start delivering value. It’s controversial: some defend it as necessary, others say it’s waste. The truth is somewhere in the middle.
What Makes Sense in a Sprint Zero
Infrastructure Setup (Good)
- Set up repositories, CI/CD, environments
- Define technology stack and code standards
- Create a base project with tools configured
Team Alignment (Good)
- Define Working Agreements
- Establish Definition of Done and Definition of Ready
- Set up tools (board, communication)
Business Context (Good)
- PO presents the product vision
- Story Mapping or Impact Mapping workshop
- Identify initial epics and prioritize the backlog
What NOT to Do in Sprint Zero
Detailed Architecture (Bad)
“Let’s define the entire architecture before coding.” That’s disguised waterfall. Define the basics and evolve.
Complete Requirements Specification (Bad)
“Let’s write all the stories before the first sprint.” Impossible. Write the first ones and detail as needed.
Long Duration (Bad)
“Sprint Zero will last 4 weeks.” If you need 4 weeks to prepare, something is wrong. Maximum: 1 normal sprint.
Ideal Duration
1 sprint (2 weeks) is enough for:
- Technical infrastructure setup
- Process definition
- Initial backlog with 2-3 sprints worth of refined items
- Working dev environment for everyone
Lean Sprint Zero (Recommended)
If you want to minimize Sprint Zero:
| Day | Activity |
|---|---|
| 1 | Set up repository, CI, environments |
| 2 | Stack, standards, tools |
| 3 | Product workshop (vision, personas, Story Map) |
| 4 | Initial backlog + refinement of first items |
| 5 | Definition of Done, Working Agreements, Sprint 1 Planning |
Alternative: Implicit Sprint Zero
Instead of calling it “Sprint Zero”:
- Week 1 of Sprint 1: setup + first commits
- First stories: “As a dev, I want to have the dev environment configured”
- Working Agreements: defined in the first retro
This eliminates the need for a sprint “that doesn’t deliver value.”
When Sprint Zero Is Necessary
- Greenfield project — everything from scratch (infra, code, processes)
- New team — everyone getting to know each other, no processes
- Stack change — migrating to a new technology
When Sprint Zero Is Waste
- Already established team — already has stack, processes, and tools
- Extension of an existing product — code and infra already exist
- Fast MVP — every day without delivering code is cost
Conclusion
Sprint Zero is acceptable when well bounded: 1 sprint, focused on infrastructure and alignment, without over-engineering. But the best Sprint Zero is one that delivers something of value — even if it’s just the CI/CD setup.