Why is Sprint Zero a Scrum Anti-Pattern‪?‬ Agile Coaches' Corner

In this episode, Professional Scrum Trainer Sam Falco answers the question: "Why do you say that Sprint Zero is an anti-pattern?"
Why do you say that Sprint Zero is an anti-pattern? “Sprint Zero” is a label applied to the indeterminate period of time used to gather product requirements and analyze them before a Scrum Team can start developing the product. Although “Sprint Zero” appropriates a Scrum term, it isn’t part of Scrum, nor is it a Complementary Practice that enhances Scrum. Sprint Zero undermines Scrum and agility.
Sprint Zero isn’t a Sprint The Scrum Guide tells us that “The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created.”
That’s enough on its own to dispel the idea that Sprint Zero is a good Scrum practice. Sprint Zero rarely has a timebox— I have seen organizations where Sprint Zero lasted for months—and no potentially releasable product is produced by it.
Sprint Zero inverts agile values The purpose of Sprint Zero is to generate comprehensive documentation. The practice rests on the false belief that we can and should understand and predict all of a product’s requirements before we start building. We often use the phrase “gather requirements,” as if they are some harvestable commodity. For complex efforts like software development, nothing could be farther from the truth. Requirements emerge as we build and are often obvious only in hindsight. Spending time trying to predict them is wasteful.
Not only does Sprint Zero value comprehensive documentation over working software, it values contract negotiation over customer collaboration. The implicit promise of Sprint Zero is that once we have defined and analyzed our requirements, we can arrive at an agreement about scope and no further interaction with customers will be necessary until the product is completed. By attempting to define scope up front, we miss out on the value of working with the customer over the course of the development effort to ensure that the customers true needs are met.
Sprint Zero undermines agile principles It delays the beginning of product development—so forget about satisfying the customer through early delivery of valuable software. It violates the principle of welcoming changing requirements. It prevents emergence of requirements, designs, and architectures.
Articulate a vision and start building Sprint Zero is nothing more than the earliest stages of waterfall disguised by an agile-sounding term. But it’s not necessary—or possible—to know everything up front. All those features and requirements that seem so important during a requirements-gathering phase often turn out to not be needed at all.
The best way to handle the uncertainty of product development is not extensive up-front analysis, but to articulate a clear product vision and start building toward it.
Want to Learn More or Get in Touch? Register for our upcoming web meetings by visiting agilethought.com/events
See available training courses at agilethought.com/training.
Visit the website and catch up with all the episodes at AgileThought.com!
Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!