Trainer Talk Podcast: Why is Sprint Zero a Scrum Anti-Pattern?

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In this episode of Trainer Talk – the supplemental series to the Agile Coaches’ Corner podcast – Professional Scrum Trainer Sam Falco addresses the question: “Why do you say that Sprint Zero is an anti-pattern?”

Listen on Google Play Music

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 timebox 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 was 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 further 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, but it also 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 upfront, we miss out on the values 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 the 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 upfront. All those features and requirements that seem so important during a requirements-gathering phase often are not needed at all.

The best way to handle the uncertainty of product development is not extensive upfront analysis, but to articulate a clear product vision and start building toward it.

Want to Learn More or Get in Touch?

Stay Up-To-Date