In November 2020 a new version of the Scrum Guide was published. The summary of changes can be found here and in a series of next few posts I will try to share my thought on some of these changes.
However, there is one change that is not listed there and that, in my opinion, is quite significant.
Potentially shippable increment is gone
Have you noticed that there is no reference to a “potentially releasable product increment” (or “potentially shippable product increment”) in the new Scrum Guide anymore? Go ahead, check it for yourself!
Does it mean that Scrum team is not required to provide a working piece of software every sprint that can be shipped to customers whenever PO/business decides to do so? No, it’s still a key part of Scrum and there are no changes here. Basically, the 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements and I suspect it’s an example of these type of adjustments.
In my opinion “potentially releasable increment”-like statements were causing some confusion, especially to teams new to Scrum. It was sometimes misunderstood and used as an excuse for not having a full-blown Definition of Done and therefore not having a piece of software that is ready to ship (usually “some” additional tests or integrations were required even though the increment was communicated as done). It also may be causing some confusion by touching upon deciding if an increment should be shipped or not which is not directly related to “producing” the product itself and is not what Scrum is about.
Now, with the change in The 2020 Scrum Guide and with an introduction of Commitments (with Definition of Done being a Commitment for an Increment) it’s, in my opinion, even more clear that Scrum Team is required to provide a “done” (implemented, tested, integrated, built, and so on) piece of software that delivers value every sprint. And that can be shipped any time after its completion – in a world of cloud software and continuous delivery it should be right after the Increment is ready (but it doesn’t have to be a case, in general). The Increment can’t require any additional work apart from making it physically available to customer (which also should be an automated process).
Not the only change
The tricky part is that it’s not the only change that happened to a definition of an Increment in The 2020 Scrum Guide. Current definition of the Increment goes as follows:
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
https://www.scrumguides.org/scrum-guide.html#increment
Sounds sensible? Yes, it does. But devil sits in the details and in my opinion, it may cause some problems. What do I have in mind?
While I think this definition fits well into a majority of backlog items Scrum team usually tackles, it may be more tricky when it comes to experiments / POCs / spikes the team has to do to get some knowledge and/or decide how to proceed further (i.e. a more complex design decision, technology choice, technology feasibility verification, etc.). Backlog items like that are not necessary based on previous increments (“Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together”), and as soon as knowledge is acquired the POCs/spike itself is not needed anymore and can be thrown away. Similarly, the work created as a result of the POC/spike usually doesn’t meet all of the DoD criteria because, as stated above, it’s often discarded.
How shall we deal with that? I think we should use common-sense here and follow the intensions behind The 2020 Scrum Guide. We need to make sure that whatever we do brings us closer to achieving a Product Goal. For sure we shouldn’t eliminate POCs/spikes from our product backlog if only running these experiments enable us to deliver value to stakeholder in the following sprints.
