Sprint Zero - A Tool To Hide Waterfall Legacy

Sprint zero is widely used antipattern to hide bigger and uglier issues. People using Sprint zero state different reasons for using Sprint zero. Some of the very common reasons include

1. We don’t have a plan yet
2. We don’t have a Product backlog
3. We need to get a handle on architecture and design

We don’t have a plan yet

People are used to having a project plan outlining all the details. They think they ‘need’ these details to get started. People using Sprint Zero provide various combinations of reasons including the need to figure out schedule, deliverable, risks, assumptions, dependencies, resource plan and other such artifacts.

A heavy upfront planning phase is one of the biggest legacy of waterfall process. Having a plan calms nerves. It provides people with an illusion of control. They feel like they know what they are doing.

In Scrum, we do plan. However, we don’t spend a whole ‘Sprint’ or more just planning. We plan, we act and we adjust our plans as we move forward. This ‘thin’ planning upsets people. They get scared. They no longer have that ‘illusion of control’.

This fear leads to Sprint zero. During Sprint zero, they can ‘plan’. They can do almost all the things done at the start of a waterfall project while ‘doing Scrum’.

Guess what. Putting a Sprint wrapper around all the waterfall like planning activities doesn’t mean you’ll be getting benefits of doing Scrum. It just means you are holding on to your crutches. You succumb to your fears of not ‘knowing’ all the details before start of the project.

Planning carried out at the start of the project is all predictive, it’s all guesswork. It’s bound to change as we move along.

What people don’t realize normally is that in Scrum projects, we spend more time planning than tradition waterfall based projects. But the planning is spread out over the lifecycle of the project. Every Sprint, planning is carried out at the start of the Sprint in the Sprint planning meeting. Team inspects and adapts (thus plans) every day. At the end of each Sprint, plans are again looked at during the review meeting. During every Sprint, team spends around 10% of the time planning. They work with the Product Owner to get the Product Backlog in shape for next planning meetings.

We don’t have a Product Backlog

This excuse comes in several flavors.

1. We don’t have a Product Backlog.
2. The items in the Product Backlog are not well defined i.e. user stories are not ready.
3. We are missing acceptance criteria etc.

See, we don’t have a good Product Backlog, they say. To come up with a ready to-go Product Backlog, they need more time. They need Sprint zero to discover all (better ones say most) of the items, define those items well, add acceptance criteria and prioritize these items. They just can’t start with a few items. The Team wouldn’t know what to do. They won’t be able to do a proper planning session. Thus they need Sprint zero.

The Product Backlog is a living document and items in Product Backlog are bound to change as the project starts progressing. Priorities will change. Acceptance criteria will change. A good chunk of the work done in Sprint zero is bound to change, producing waste.

A good Product Backlog goes a long way in helping the team having a great planning session and hit the ground running. But the project can’t be held hostage until the Product Backlog is in ‘good enough’ shape. The lack of details or items in the Product Backlog will become painfully apparent once the team starts Sprinting and the team will certainly come up with ways to move ahead. Product Backlog will keep getting better.

We need to get a handle on architecture and design

This is yet another legacy of waterfall process. Many companies doing Scrum feel terrified that they don’t have a ‘solid’ idea of what their design will look like. They get cold feet while realizing they don’t have a well thought out architecture. To them it sounds mad to rush to start the project without having all the architecture and technology related issues explored, debated and documented. Many architects and lead designers abhor starting the ‘development’ without doing all the design work and ‘singing it off’. Conveniently, Sprint zero is added right at the start of the project.

Some companies and system integrators do what they call as ‘impact assessment’. This is yet another term to do carry out detailed inspection and design. In some of the cases, I have seen companies spending 100K on impact assessments while development cost of the actual change turned out to be 30K.

Sprint zero is nothing but an effort to do heavy design upfront, well, as heavy as possible. We all know the pitfalls of heavy upfront design. It’s one of the reasons we are doing Scrum. We don’t stuck in the heavy design rut. Instead, our design and architecture emerges as we build business functionality. We prove our architecture by building and delivering business value. We remain open to change. Trying to put together bulk of design and architecture in Sprint zero goes against all of this.

Learn more about Scrum and Agile in one of Scrum Certification Courses.

© Faisal Mahmood

Google+