Antipattern of the Month: Sprint Zero

"Sprint 0 is like Casper, the friendly ghost. Well-meaning, but creepy." - Nitin Khanna

"Sprint Zero" is a euphemism sometimes used to describe the initialization of an agile project. It can include such activities as the drafting of a Product Backlog, infrastructure set-up, architectural envisioning, and the resourcing of team members. In Scrum, there is no concept of a "Sprint Zero" which encompasses such things. It isn't the nature of these activities which make the "Sprint Zero" concept invalid - obviously, they do need to happen. The problem is that a "Sprint Zero" does not usually result in an increment which the Product Owner can value, and it may not even be time-boxed for that purpose.

"Sprint Zero" is an example of a wider antipattern of "Special Sprints" which do not release value, or which imply that other Sprints will not. Other examples include:

• "Hardening Sprint": If a team's definition of done is inadequate, or is not being met, technical debt can be expected to accumulate. A so-called "Hardening Sprint" is an attempt to pay off this debt rather than improve the team's process and thereby stop debt from arising.

• "Release Sprint": Each Sprint must result in a potentially releasable increment, regardless of the number of teams and deliverables involved in a release, so batch sizes of undelivered work can be minimized and controlled. A so-called "Release Sprint" would therefore also be a contra-indication to Agile practice.

What then should we call the process where we perform essential set-up activities? Well, you can of course number or label Sprints in any way you like. Simply calling an iteration "Sprint Zero" is not necessarily any more of a problem than having a Sprint 1 or even a Sprint -1. What matters is that each and every Sprint is timeboxed, planned, reviewed, subject to a retrospective, and delivers a potentially releasable feature of value to the Product Owner, no matter how small it may be. When people talk about "Sprint Zero" that isn't what they typically mean though. It's often just an agile-sounding term for pre-Sprint initialization work where no increment of product value is provided at all. In truth, it is not a Sprint and should not be described as one. To be a Sprint, something of value must be delivered in a clearly time-boxed fashion.

A "Sprint Zero" is sometimes identified retrospectively once initialization has been completed. In this situation, it may not even have been time-boxed in the first place. For the purposes of transparency and control, a simple, WIP limited Kanban of project set-up tasks may be better than trying to use Scrum Sprints in a precocious and inappropriate manner.

The challenge in Agile development is to effect initialization in such a way that sprinting, and the delivery of value, can begin as soon as possible. In theory, a team only needs enough work on a Product Backlog to start one genuine Sprint. The rest of the backlog can be refined on a just-in-time basis. However, this increases certain risks such as a failure to prepare enough work for the next Sprint Planning session, and so a rolling horizon of perhaps two or three Sprints' worth of work might thus reasonably be observed.

Remember that each increment must provide some valuable functionality, no matter how trivial. If most of an early Sprint is spent on establishing technical foundations, then it is advisable to deliver just enough MVP functionality to validate the foundation created. This might be a transactional user story or scenario which proves that essential architectural layers are working. Sometimes this is referred to as a "tracer bullet" or as a "stovepipe prototype."

"Sprint Zero" is Antipattern of the Month at agilepatterns.org

Sprint Zero

Intent: Set up an Agile project, while contextualizing unplanned initialization overheads in Agile terms.

Proverbs: The first step is always the hardest.

Motivation: Agile methods typically have an operational delivery focus. They do not always address strategic or tactical matters such as the resourcing and initialization of projects. This deficit may go unnoticed by Agile development teams which have a duty to deliver value as quickly as possible. As such, these teams are often tempted to start iterative and incremental development before business or other important stakeholders can engage in the value stream. When the first Sprint fails to deliver business value, it is then contextualized and dismissed as “Sprint Zero.”

Structure: A team attempts to sprint. However, there is no Product Backlog from which a Sprint Backlog can be drawn and completed within the associated time-box. Other significant elements of the project environment may also be missing. This first attempt at an iteration does not, therefore, result in a potentially releasable increment of value. Work done by the team in trying to overcome these matters is correlated to a so-called Sprint Zero. This pseudo-Sprint does not necessarily match the original time-box since the initialization work is unplanned and unsized.

Applicability: This anti-pattern is often found in organizations where product ownership is weak and/or portfolio management is poor. The assignment of teams to a project will not be synchronized with other elements of project initiation, such as the resourcing of a Product Owner, the drafting of a backlog, the availability of development or test environments, or the approval of a project vision or business case.

Consequences: A poorly controlled project may commence with an ill-defined Sprint Backlog or unforeseen dependencies, and the team will need to resolve these impediments before value can be delivered. Most or all of this work may be unforeseen and unplanned. Retroactively fitting such project initiation tasks into a time-box may create the illusion of control, but no value will have been delivered in this pseudo-Sprint and any associated metrics are likely to be deceiving. Also, the wrapping of work post-facto does not represent the genuine time-boxing of activities and can indicate a poor grasp of Agile practice by the stakeholders concerned.

Implementation: Sprint Zero is not recognized as a tenable construct in any Agile methodology, although the anti-pattern is frequently encountered and is commonly assumed to be a valid practice.

See Also: Iteration, Product Backlog