Sprint Zero: What to Estimate Before You Even Start

Sprint Zero is the setup sprint before real delivery begins. It's often treated informally - a period of "getting ready" with no real commitments. That's a mistake. What you do (and don't do) in Sprint Zero shapes the reliability of every sprint that follows.

What Sprint Zero is for

Sprint Zero is not feature development. Its outputs are:

• Development environment setup and verified on all machines
• CI/CD pipeline established and running
• Core architectural decisions made and documented
• A refined, estimated initial backlog ready for Sprint 1
• Team working agreements defined (Definition of Done, review process, communication norms)

How to estimate Sprint Zero

Sprint Zero work is mostly setup and discovery, so standard story points don't fit well. Instead, use tasks with time estimates (hours), or break Sprint Zero into a fixed timebox (one to two weeks) and track what gets done.

What belongs in the backlog vs. Sprint Zero

Sprint Zero should not include:

• Feature development (this inflates scope and creates incomplete work)
• Estimating the entire product roadmap (premature; you don't know enough yet)
• Setting velocity (you have none)

Setting expectations for Sprint 1

By the end of Sprint Zero, you should be able to answer: What is the team's initial capacity estimate? What does the first sprint's committed scope look like? These are planning questions, not delivery questions, but having good answers to them makes Sprint 1 predictably successful.

The common failure mode

Sprint Zero turns into a month of architecture design with no deployable output and no refined backlog. When this happens, Sprint 1 starts with the same planning problems Sprint Zero was supposed to solve.

Sprint Zero is an investment. Timebox it, define its outputs, and hold to the timebox. The sprint after a well-run Sprint Zero feels effortless.