BROADCASTS.com

b'

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?

\\u201cSprint Zero\\u201d 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 \\u201cSprint Zero\\u201d appropriates a Scrum term, it isn\\u2019t part of Scrum, nor is it a Complementary Practice that enhances Scrum. Sprint Zero undermines Scrum and agility.

Sprint Zero isn\\u2019t a Sprint

The Scrum Guide tells us that \\u201cThe 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.\\u201d

That\\u2019s enough on its own to dispel the idea that Sprint Zero is a good Scrum practice. Sprint Zero rarely has a timebox\\u2014 I have seen organizations where Sprint Zero lasted for months\\u2014and 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\\u2019s requirements before we start building. We often use the phrase \\u201cgather requirements,\\u201d 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\\u2014so 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\\u2019s not necessary\\u2014or possible\\u2014to 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!