What is so wrong about this concept called 'Sprint Zero'?
Often we end up hearing some of those inconsistent and unsure vocabulary around Scrum and one such term is ‘Sprint Zero’.
Let us explore what is this term called ‘Sprint Zero’ and how it has nothing to do with Agile even before tagging it with Scrum as a thoughtful practice.
Sprint Zero – Definition:
Its a label applied to the indeterminate period of time used to gather product requirements, analyze them and come up with big design upfront (BDUF) before the Scrum Team can start building the product.
Even though it looks more appropriate to associate ‘Sprint Zero’ with Scrum, neither its part of Scrum or put it more specific – it has nothing to do with Scrum nor is a complimentary practice that enables more Agile thinking within the team.
Even though it looks more appropriate to associate ‘Sprint Zero’ with Scrum, neither its part of Scrum or put it more specific – it has nothing to do with Scrum nor is a complimentary practice that enables more Agile thinking within the team. Sprint Zero actually undermines Scrum and Agility.
According to Scrum Guide,
“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.”
Sprint Zero rarely has a time-box and it doesnt come up building any potentially releasable product increment. Sprint zero actually inverts the Agile Values.
Photo by Jack Gisel on Unsplash
Sprint Zero inverts the Agile Values. What does it mean?
It actually means that Sprint Zero promotes opportunity to create more ‘Comprehensive documentation over 'Working Software’ , ‘Following a plan' more over 'Responding to change’ and find time and tactics for 'Contract negotiation' over 'Customer collaboration’
Since the purpose of Sprint Zero is to come up comprehensive documentation following a plan to do things upfront, it shows some of the practices with false beliefs, viz;
- Trying to measure progress with comprehensive documentation and plan which delay measuring progress with working software (Remember the Agile Manifesto: Working Software over Comprehensive Documentation)
- Instead of ‘welcoming change’, now take futile measures towards exhaustive analysis, documentation and design upfront part of the plan for Sprint Zero. Requirements emerge as we start progressing to build working software and no approach of gathering upfront expectations can help predict the future (Remember the Agile Manifesto : Responding to change over Following a plan)
- Gather requirements upfront and hold an illusion of arresting the uncertainty / complexity that unfolds with the future. Further this mindset gives us a false hope of negotiating with the customer on a certain plan (around scope, time and effort – all identified and finalized) for the future. This diminishes the value behind collaboration seen with Just-in-Time (JIT) and Just Enough (JE) practices otherwise (Remember the Agile Manifesto: Customer Collaboration over Contract Negotiation)
It not just stops here with the Agile Values but also undermines the actual sense around many Agile Principles.
For example, it delays the beginning of product development which violates the principles of ‘early and often delivery of working software’ and ‘welcoming change’. It also prevents ’emergence of requirements, design and architecture’.
Sprint Zero is nothing more than the earlier stages of Waterfall Software Development covered by an Agile sounding term.
Sprint Zero is nothing more than the earlier stages of Waterfall Software Development covered by an Agile sounding term.
The best way to handle the uncertainty is not through ‘big upfront requirements collection, analysis and design’ but to articulate a clear product vision along with a road map and start building towards it.
Are you aware of all these implications and what this term ‘Sprint Zero’ undermines / inverts?