We do Scrum, but…
“Scrum — We can’t release an increment every Sprint”
Are you serious? — episode 16
The Scrum Guide says:
“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.” — SG
Many struggle with this. I often hear remarks like:
- How can we possibly have something releasable at the end of the first Sprint?
- It will take us months to have a Minimum Viable Product (MVP) ready that has the quality our customer would expect. Before that we can’t have anything really releasable.
- The chunks of software that we wish to release are larger than one Sprint.
You might think that I tackled this issue before:
Or maybe you think that I am now going to contradict what I wrote in above article. But I will not!
This is a different topic. That article was addressing a working increment. This article is about actually releasing a working increment! Not convinced? Let’s check what the Scrum Guide has to say about this:
“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.” — SG
And
“The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done”.” — SG
You will find the term “potentially releasable” 6 times in the Scrum Guide. You will NOT find the word “releasable” without “potentially” in front. The Scrum Guide never mentions that you MUST release an increment.
Here’s another perspective on it:
“At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”.” — SG
Scrum says “Done” = “Potentially Releasable” = “Usable condition”
There’s more:
“The increment must be in useable condition regardless of whether the Product Owner decides to release it.” — SG
So the increment should be usable and the Product Owner may decide NOT to release the increment. This is a key phrase!
But… when you’re not going to release, why the hassle of creating this potentially releasable increment (at least) every Sprint?
This brings us to empiricism, the core of Scrum:
- Knowledge comes from experience.
- You make decisions on what is known.
- You wish to be transparent by creating an increment that meets the team’s Definition of “Done”.
- You inspect this “Done” increment.
- Based on what you learned from the increment you adapt; you stay on course or change course.
You could create requirements, you could create a design, you could make a fantastic story map. But at the end you still have nothing.
Scrum says: build something and show it, then discuss it.
Use short feedback loops to move ahead. This will allow you to really build what your stakeholders want. You don’t have to release your increment. If you can, by all means do so. What is better than having regular fast feedback from customers actually using your product? This is a main potential benefit of Scrum. But for Scrum it is not a goal in itself.
Scrum is a framework that can be used for many situations. For teams that release fast (every Sprint or multiple times per Sprint) and for teams that build increments that take more Sprints to release.
Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.
My twitter profile is https://twitter.com/WJAgeling
