Why using Sprint 0 is a cardinal sin for all Scrum Masters

A Scrum Master using Sprint 0 is just as strange as an astronaut believing the world is flat. Scrum Masters should know better!

Unfortunately, there still are many Scrum Masters who start their new teams with Sprint 0. In this article I will try to persuade you there is no convincing reason to use Sprint 0.

So let’s start by figuring out why Scrum Masters introduce the concept of Sprint 0 to their team.

What is Sprint 0?

There is no official definition of Sprint 0, as it is not part of Scrum.

Sprint 0 conflicts with the core of Scrum

Imagine you would strip Scrum of everything to reach the core of what Scrum is about. You would remove all the roles, events, artifacts and rules of Scrum to reduce it to its absolute essence.

Scrum boiled down to a single sentence for a software development context would be:

Deliver a working product every Sprint

Sprint 0 clashes with the Empiricism of Scrum

The foundation of Scrum is empiricism. Empiricism asserts that knowledge comes from experience and you should make decisions based on what is known. By doing you will learn more. You may use this learning to do better than you did before.

By starting with Sprint 0, you have no product increment to inspect at the end of the Sprint. Therefore, your team will not run into the challenges involved with doing a real Sprint.

Sprint 0 results in reduced transparency: you will not encounter the real obstacles involved with doing Scrum. This leads to worse inspection and less adaptation.

You can read the rest of the article here

Look at Capability, not Title.

Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team?

With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment.

This has unearthed strong opinions. Unfortunately, they don't converge on a single word or phrase.

A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create” a “Done” increment.

Read the complete article here.

To read the rest of the articles and posts... You can subscribe to the newsletter here