Sprint-zero

Why Have We Been Using Sprint Zero?

Could this be a tool to hide Waterfall legacy? 

Key Takeaway

Are you really embracing Scrum or putting a Sprint wrapper around your waterfall-like planning?

Sprint zero is a widely used anti-pattern to hide bigger and uglier issues. People who use Sprint zero give different reasons for using it. Some 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.

________________________________________________________________________________

Featured Course
You will learn within the Scrum framework doing iterative incremental development.

Professional Scrum Developer (PSD) Java

________________________________________________________________________________

Do we 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 the schedule, deliverables, risks, assumptions, dependencies, a resource plan and other such artifacts.

A heavy upfront planning phase is one of the biggest legacies of the waterfall process.

Drop your fear

A heavy upfront planning phase is one of the biggest legacies of the 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’.

Key Takeaway
The Scrum Master, the person in charge of running the process,
asks each team member  three questions:
1. What did you do yesterday to help the team finish the Sprint?
2. What will you do today to help the team finish the Sprint?
3. What obstacles are getting in the team’s way?
That’s it. That’s the whole meeting.
Jeff SutherlandScrum: The Art of Doing Twice the Work in Half the Time

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 the 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 the 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 realise is that, in Scrum projects, we spend more time planning than traditional waterfall based projects. But the planning is spread out over the lifecycle of the project.

In every Sprint, planning is carried out at the start of the Sprint in the Sprint planning meeting. The 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, the team spends around 10 percent of the time planning. They work with the Product Owner to get the Product Backlog in shape for future planning meetings.

And what about that Product Backlog we don’t have?

This excuse comes in several flavours:

  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 the 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 prioritise these items. They just can’t start with a few items. The Team wouldn’t know what to do. They wouldn’t be able to do a proper planning session. Thus, they need Sprint zero.

The Product Backlog is a living document and the items in a 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 have 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. The Product Backlog will keep getting better.

Can we get a handle on the architecture and design?

This is yet another legacy of the 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 when they realise they don’t have a well-thought-out architecture.

To them, it sounds mad to rush and 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.

We prove our architecture by building and delivering business value.

Some companies and system integrators do what they call an ‘impact assessment’. This is yet another term to carry out detailed inspection and design. In some of the cases, I have seen companies spending $100K on impact assessments while the development cost of the actual change turned out to be only $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 do Scrum.

We don’t get 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 the bulk of the design and architecture in Sprint zero goes against all of this.

 

If you think this post is interesting, please share using the buttons below!
#scrum #sprintzero #waterfall

This article has been adapted from the original one published at Accelright’s blog. Puzzle image courtesy Chadou99 of freeimages.com





There are no comments

Add yours

x
freshmail.com powered your email marketing