Convener: Iain McKenna
List of Participants: Andrew Lefrancq, Gergana Georgieva, Stephen O’Malley, Martin Tecjeby, Dave Edwards, Steven Olds, Paul Exley, Paul Whelan, Klaus Lindemann
Discussion: There is a need to do some work before the first Sprint starts. This includes defining the vision and goals, putting together a development team, creating an initial Product Backlog, refining the initial Product Backlog to understand enough work for the first Sprint – which also informs starting state architecture and design. This work should be accomplished in the shortest time possible so that the team can start to get feedback on real software. As this work in itself does not deliver a potentially shippable product increment, this can not be a Sprint as one of the fundamental rules of Scrum is that each Sprint produces a potentially shippable increment of the product. Calling this pre-sprinting activity a Sprint is not just a matter of language as it sets a precedent early on with people that Sprints do not have to deliver potentially shippable increments of the product. There were also some examples given of teams using multiple Sprint Zeroes (0.1, 0.2… up to 0.14) and how this just perpetuated Big Up Front Design which everyone agreed was a bad thing.
The discussion also covered Product Backlog Refinement in order to ensure common understanding and then diverged onto release planning and how that can be done simply and quickly using velocity and the Product Backlog but also the need to revise the release plan at the end of every Sprint.
Recommendations: Activities that are done in order to get ready for the first Sprint should not be called Sprint Zero. They can be called anything other than a Sprint but people should be clear about what they need to achieve before they can start sprinting.