There are no Sprints 0 in SCRUM - deep dive

There's quite a bit to dissect here.

I'd agree that if "Sprint 0" has a lot of big requirements engineering, architecture, design, or infrastructure setup, then that would indeed be an anti-pattern and not consistent with the value of responding to change or the principles related to welcoming changing requirements, maximizing the work not done, and emergent requirements, architectures, and designs.

However, I'd suggest that because Scrum is an incomplete framework, there are prerequisites that must at least have been started before the first Sprint can begin. Scrum's requirements are fairly lightweight - the team needs to exist, have all of the accountabilities accounted for within the team, have enough of a Product Backlog created and refined to plan and execute a first Sprint, and have a Definition of Done to help guide the planning and execution. There are a number of things that Scrum doesn't address, though, such as how the team is formed, how the scope (the initial Product Goal and creation of the Product Backlog) is created, how the team obtains the funding, and agreeing on an initial way of working (everything from Sprint cadences to estimation techniques to various tools to support the team).

Different frameworks and methodologies call this chunk of work different things. For example, Disciplined Agile calls it Inception. ISO 12207 has a number of processes and objectives related to defining the project's processes and life cycle, planning, and business analysis, and stakeholder needs definition that have components that should be "done" (but perhaps revisited on a regular basis) fairly early in the effort. There's a line between just-enough and too-much of these activities, but doing just enough is needed to maximize the successes of early Sprints.

I would disagree that Scrum is not talking about delivering external value. Although it's not explicitly stated (at least in the November 2020 revision of the Scrum Guide), I do believe that the intention is for every Sprint to deliver value to at least one stakeholder or stakeholder group other than the Scrum Team. Consider that every Sprint contains a Sprint Review, during which the team presents the work they have done and the progress they have made toward the Product Goal to key stakeholders. If the team is not at least able to demonstrate that the work that they have done is valuable to stakeholders, then I'd suspect that the key stakeholders would be very disappointed. However, the value doesn't necessarily need to be in the form of a product. Especially in early Sprints, demonstrating that the team is learning the domain and is able to begin to prove that they are capable of addressing problems.

I would also disagree that the Increment is not required to be usable. In fact, the Scrum Guide says that "in order to provide value, the Increment must be usable", and that "the entire Scrum Team is accountable to creating a valuable, useful Increment every Sprint". If the team must create a valuable, useful Increment and that a valuable Increment is a usable Increment, then the Increment must be usable. What it doesn't say is that an Increment has to be used or put into use. The important thing is to make the product or service usable in some context to allow for real feedback from stakeholders, not necessarily all of the users or potential users of the product or service. This real feedback is crucial for inspecting and adapting the Product Backlog.

So what is the real problem with Sprint 0?

That's the question to ask. If it doesn't actually count as the first Sprint, why?

Real life examples:

• the Product Owner is unable to discern and optimize its value
• it doesn't establish empirical process control
• no Done increment is created
• it is not timeboxed as other Sprints

Hi guys, thanks for the feedback.

Thomas Owens, I agree with all you wrote above :) Let's imagine a product which use image recognition from the Cloud AI. At the beginning there can be a lot of questions and unknowns. How fast would it work? Can we use it to recognize faces? How fast and reliable would it be? Can we use it to make our product? If not, are there any alternatives?

Verifying assumptions about the technology can be important aspect for the Stakeholders. Should we even build the app without verifying them? It probably depends.

But what about "usable"? IMHO "usable" means that one can get value from the Increment after delivering to it to him/her without further adaptations. I'd argue that in some situations we can use PoC results as well ;) 

At the same time I really like the notion of "usable by Stakeholders", although I'd like to think about it more. It seems to be a valid point.

And as always I really like Ian's powerful questions. Really appreciate!

Let's imagine a product which use image recognition from the Cloud AI. At the beginning there can be a lot of questions and unknowns. How fast would it work? Can we use it to recognize faces? How fast and reliable would it be? Can we use it to make our product? If not, are there any alternatives?

Some of these questions aren't good for a product development framework like Scrum.

If you're building something new and novel, it may not be possible to answer questions about performance until you've first built the functionality. If you know that the functionality is possible, then you can use Scrum as a framework for developing a product and regularly getting it in front of stakeholders and getting their feedback. Their feedback can be not only about the functional characteristics, but about performance, reliability, and other attributes of the product.

However, if you're still in a research phase, perhaps a product development framework isn't where you should be looking for your approach. Something like Lean Startup may be more beneficial for the kind of exploratory work that you're doing. There may be some similarities, but some of the constraints of Scrum - producing a usable Increment every Sprint, having well-defined Product Goals and Sprint Goals, and a coherent Product Backlog - may add more overhead than should be incurred on such a project.

Verifying assumptions about the technology can be important aspect for the Stakeholders. Should we even build the app without verifying them? It probably depends.

From my perspective, if you've chosen to use Scrum as the framework for your development methodology, you've already decided that you should build something. There may be questions about the details about what to build or the order in which to build it, but you've already committed a team for at least one Sprint to do the building. Depending on your organization, you've probably committed to more than a single Sprint, when you look at what it takes to assemble the team with the requisite knowledge and skills.

But what about "usable"? IMHO "usable" means that one can get value from the Increment after delivering to it to him/her without further adaptations. I'd argue that in some situations we can use PoC results as well ;)

At the same time I really like the notion of "usable by Stakeholders", although I'd like to think about it more. It seems to be a valid point.

I don't think that "usable" means "get value after delivering without further adaptations".

Usable means that someone can sit down and use it. There's no specification of where that use happens. For example, if you're using Scrum to build a system (hardware, software, or both) for an airplane, do you want "use" to happen in a passenger plane at 30,000 feet? Probably not. The first use would come in system integration and test laboratory to measure and observe the system in a controlled setting, often in isolation. There are a whole bunch of downstream activities involving ground tests, flight tests with expert pilots and no crew, certification of the system, and finally fielding of the system.

Usable means that the real thing is available for stakeholders for inspection. It could be software deployed to a test environment. It could be a first-article in a laboratory. As long as the stakeholders can interact with it, it's usable.

As usual, @Thomas Owens has some great things to say. He constantly comes up with related and tangential items that I have never looked at.  While I agree with everything he and @Ian Mitchell have said, I'm going to offer up a different perspective. 

Let's imagine a product which use image recognition from the Cloud AI. At the beginning there can be a lot of questions and unknowns. How fast would it work? Can we use it to recognize faces? How fast and reliable would it be? Can we use it to make our product? If not, are there any alternatives?

Some of this work seems like refinement activities that would be accomplished via a Proof of Concept.  Scrum can be used to build a Proof of Concept and I have done it multiple times.  But at that point, what you are building is the Proof of Concept and not a product.  The rules of inspection and adaption are slightly different and your definition of usable is usually modified.  However, the stakeholders are never the Scrum Team themselves.  Stakeholders are external to the Scrum Team.  Almost every reference to "stakeholders" in the Scrum Guide state things like "the Scrum Team and its stakeholders" or are in context with the stakeholders being external to the Scrum Team.  So if the work you are doing is only valuable to the Scrum Team, you are in effect doing discovery or refinement.  However, if you are creating work that people external to the team can use and inspect, you are delivering valuable increments as described in the Scrum Guide.

These external stakeholders do not have to be customers.  Some of them can be internal.  For example in your statement, you mention mention how "fast and reliable" would it be.  That could also be a concern for your IT organization as they will have to provide the bandwidth to use the product, they will most likely manage the cloud environments.  So you could do a Proof of Concept by identifying the proper stakeholders and always providing something that can be used and inspected by them. 

As for the name "Sprint 0" I see no problem with the name.  There is nothing in the Scrum Guide that indicates how your name your Sprints.  Zero is the beginning of almost all numbering systems. As long as the work you are doing is delivering a usable increment for inspection by the identified stakeholders, you can call it whatever you want. The real objection to using "Sprint 0" is because people would have them go on for weeks or even months before they started to do valuable work.  In my experience that time is usually spent creating process manuals, defining what a story point means, creating a workflow that will satisfy every possible situation that could be encountered, etc.  The idea of Scrum is to start working, then inspect and adapt both the product your create as well as the way you work to create it.  The idea that every Sprint will be identical is a fallacy in my opinion.  No one ever gets everything right.  

"without delivering any value to the customers"

Is 'value' only applicable from the eyes of the end-user? Or can the Scrum Team, specifically the Developers be the receivers of this value?

An example Sprint Goal: Customers are able to receive updated versions of our product within 24h.

To me, I might expect to see some CICD PBIs, perhaps some automated testing framework PBIs etc. Despite these things typically being a 'Sprint 0' type of thing, there is still an increment there - the Product has moved forward. Even though the customer's might not 'see' anything, they have received value, but importantly so have the Developers and Scrum Team - they are able to receive a rapid ROI and close their feedback loop.

I often find teams that want to use a Sprint 0 don't see themselves as important enough to be value-receivers. If you can coach them out of that mindset, Sprint 0 just gets renamed to Sprint 1, there is a usable increment, and happy days.