Can we have a Sprint Zero with no deliverable code?

Question

According to Ken Schwaber, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.”

Also the Product Owner is supposed to collaborate closely with the team to create this product vision. This is desirable because having participated in this process, the team will have a deeper understanding of the vision.

Given these, in our large organization it takes time and several meetings with the stakeholders to get consensus on the vision and product direction. So, is it OK to have a Sprint 0 with no deliverable code?

Answer 1

I believe your problem is in trying to shoe horn a process which comes prior to the initiation of your sprints, into an initial sprint. Your situation raises two questions, in my opinion.

1. Is it Scrum methodology to have a sprint without a deliverable that can be shipped?

Typically not.

Scrum intends to avoid detailed up front planning and the concept of getting things, "done", is a key tenant. While you can be creative when you define, "done", ultimately the concept of, "sprint 0", is not part of the Scrum philosophy, nor is a plan that doesn't deliver a feature that can be shipped.

2. Can I adapt Scrum to fit my needs?

Sure - but it wouldn't be Scrum.

That said, there's no reason why you can't implement Scrum purely, if that is your aim, in the situation you have described. While the quote you give from Ken Schwaber is true, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog", that doesn't exclude the possibility that in your organization more than that is required.

This extra planning prior to a series of sprints commencing needn't be defined as, "sprint 0". If your development ecosystem requires project planning due to internal policy then it's perfectly legitimate to just call a spade a spade - refer to this as a distinct process outside of your implementation of the Scrum methodology.

Answer 2

is it OK to have a Sprint 0 with no deliverable code?

Remaining true to Scrum framework, the answer would be NO.

Can you time-box the Sprint 0? If the answer is no then you would be violating two important factors of Scrum framework, first time-boxing and the second potentially deliverable code at the end of each sprint. As you have mentioned that the organization takes time and several meetings with the stakeholders to get consensus on the vision and product direction, so time-boxing this exercise could be hoping against hope.

Which is why Mike Cohn calls this portion a project before the project:

During this project-before-the-project, the early team members (perhaps just a future product owner) can work toward creating an initial product backlog, finding or hiring team members, setting up the technical environment, and so on.

One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules.

Even the concept of Sprint Zero is debatable amongst the founding fathers of Agile, as Alistair Cockburn stated:

I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented "Oh, that was Sprint Zero!"to get the peasants with the pickaxes away from his doorstep.

... and then others thought that was a great answer and started saying it, too. ... and then it became part of the culture.

and in the words of Ken Schwaber:

Exactly ... sprint 0 has become a phrase misused to describe the planning that occurs prior to the first sprint ... and since planning creates artifacts that often change, it should be minimized prior to the first sprint, and then occur every sprint at the sprint review/sprint planning meeting (just in time planning)

Answer 3

TL;DR

There are often debates between Scrum practitioners about whether to have a Sprint Zero or not. You can side-step the various arguments by redefining what the Sprint Goal will be for the first sprint, and by adjusting expectations of what will be demonstrated in the Sprint Review.

Sprint Goal

Sometimes, the drive to have a "Sprint Zero" seems like a need to have a tool-chain or architectural sprint without a concrete deliverable. If you dig deeper, though, the real goal is often to avoid counting the first sprint into your team's velocity. However, all project-related work should be carried on the Product Backlog as a visible cost to the project, so please don't fill your first sprint with invisible work.

The technically-correct answer within the framework is to ensure that the necessary architectural, tool-chain, and other infrastructure stories are included on the Product Backlog. For example, the Sprint Goal of the first sprint could be something like:

Install the development infrastructure needed to kick-start the project.

You might even need several such sprints at the start of a project; that's okay, too. The user stories accepted into those initial sprints would be selected to meet the defined Sprint Goals.

User Stories and Sprint Review

A literal interpretation of the Sprint Review process seems to make non-feature stories a no-no. However, this isn't really so. The process goal is to make progress (or the lack of it) visible to stakeholders, and to provide an inflection point within the project to gather stakeholder feedback. This generally works best with tangible or user-accessible features, but anything that you can demonstrate in a visual or engaging way will suffice.

For example, your team's first Sprint Review could certainly demonstrate developer-facing deliverables such as:

• The status screen of the project's continuous integration server.
• The web interface for the new source control system.
• A live demo of "Hello, World!" compiling with the team's tool-chain.

It is up to the team, including the Product Owner and the Scrum Master, to educate the stakeholders about the need for these project prerequisites. Sweeping these deliverables under the rug through the "Sprint Zero" mechanism is a way to side-step the need to educate the organization, but it ultimately cheats stakeholders and the team out of the full benefits of a transparent process.

Answer 4

Mind that Scrum talks about potentially shippable increments (PSI) as opposed to potentially shippable code! Of course you can ship code, but you can ship other things as well. For example, a product-vision document could be a shippable increment. Sprints with the goal do gain insight are often called Exploration Sprints. They are not unusual.

In general, the idea of the shippable increment is to make you define a clear-cut goal for your iteration. That's the only way to make your progress measurable. You cannot measure your progress on the task "understanding the problem domain", but you can measure the progress on creating a document that contains the product vision. Because in the latter case you can discuss the result and find out whether it's acceptable or not.