Skip to main content

There are no Sprints 0 in SCRUM - deep dive

Last post 07:16 am July 8, 2021 by Ryan Brook
6 replies
03:30 pm July 4, 2021

To pass any of the PSPO or PSM certifications you have to remember that there are no Sprints 0 in Scrum. End of story? Not necessarily.

Recently I've been thinking about this topic and would like to "challenge it" a little bit as a food for thought 😉

First, when we talk about Sprint 0 we mean a common antipattern when the Team is working on the infrastructure / foundations (e.g. database, data access layer) without delivering any value to the customers. But is it really always a bad thing? Are there any rare exceptions?

We know that "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint". But at the same time  there are many types of value. Scrum is not talking about the necessity to deliver value to the customer (external value). It is also not required that the increment is usable by the customer. So it can be internal value, usable internally (e.g. PoC). So what is the real problem with Sprint 0? 

Scrum is based on empiricism. The aim of the Sprint is not only to create value, but also to experiment and validate assumptions. In many cases these are assumptions about the value / utility of new customer-oriented features, but sometimes it can be assumptions about technology. In my opinion at the end of the Sprint it is important to verify at least one assumption by closing the feedback loop and get input enabling further, better planning. And this is exactly what traditional "working on foundation" does not provide. It's commonly just a progress without verifying the direction.

Having said all this, I would like to point out that in my opinion the most important type of value is the value we create for the client. Spending too much energy on verifying the technology, especially in the first sprints, is not something I'd recommend in most cases. Even if we very assumptions along the way.

What is your opinion? I will be grateful for your comments and remarks.


05:53 pm July 4, 2021

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.


06:07 pm July 4, 2021

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

06:52 pm July 4, 2021

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!


08:47 pm July 4, 2021

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.


04:28 pm July 6, 2021

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.  


07:16 am July 8, 2021

"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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.