The 2020 version of the Scrum Guide defines an artifact by the name of “Increment.” This represents a renaming of an already existing Scrum artifact that historically was referred to as either “potentially releasable product increment” or a “potentially shippable product increment.”
I believe there is a benefit to this renaming. However, the new name and its formal definition in the Scrum Guide does not fully address the breadth of work types (i.e., product backlog item types) that a team can accomplish during a sprint. In this blog, I will address the benefits of the renaming, and the incongruence of the definition of Increment when applied to knowledge-acquisition work.
Let me begin by quoting the 2020 Scrum Guide definition of an Increment.
Scrum Guide Definition of Increment
The following is the description of an Increment from the 2020 Scrum Guide.
- 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.
The Benefits of a New Name
I like the idea of dropping “potentially releasable” or “potentially shippable” from the name of the artifact. Every time in class or during coaching that I introduce the concept of work completed during a sprint I am obligated to point out that potentially releasable or shippable does not mean that the completed work actually has to be released, shipped, delivered, deployed (or whatever your favorite verb is in this context).
Releasing or shipping is a business decision, which is frequently influenced by things such as “Do we have enough features or enough of a customer workflow to justify a customer deployment?” or “Can our customers absorb another change given that we just gave them a release two weeks ago?”
Potentially releasable or shippable is better thought of as a state of confidence that what got completed in the sprint is actually done, meaning that there isn’t materially important undone work (such as important testing or integration and so on) that needs to be completed before we can ship the results from the sprint, if shipping is our business desire.
Granted, it’s not that hard to clear up any confusion people have with potentially releasable or shippable, but it’s an unnecessary mental exercise. Just calling the artifact an “Increment” eliminates the confusion of “does 'potentially' mean we actually have to ship it?” And dropping “releasable” or “shippable,” at least for me, makes a clear the separation of two distinct concepts:
- building something of value to a high degree of confidence (as defined the by the Scrum Team’s definition of done); from
- releasing or shipping something of value
So, changing the name is a good thing from my perspective.
What About Knowledge-Acquisition Work?
My issue with the term Increment, and how it is defined in the 2020 Scrum Guide, is that while it applies to many types of work that a Scrum Team might perform, it is difficult to reconcile at least one particular type of work. What about knowledge-acquisition work?
Sometimes we need to create a product backlog item that focuses on knowledge acquisition. Perhaps we don’t have enough exploitable knowledge about the product or the process of building the product to move forward. So, we might need to explore. Such exploration is known by many names: prototype, proof of concept, experiment, study, spike, and so on. They are all basically exploration activities that involve buying information.
Let’s say that a Scrum Team needs to evaluate two architectural options. So, this sprint it decides to create a quick and dirty prototype of each option and run a series of tests across each prototype to collect data on which is the more viable longer-term option. The end result (deliverable) is a decision as to which option to choose and why.
Does the resulting work constitute an Increment? Let’s compare it against the 2020 Scrum Guide definition of an Increment.
| Scrum Guide Definition of Increment | Does Knowledge Acquisition Work Align? |
|---|---|
| Concrete stepping stone toward the Product Goal | Yes, buying relevant information is a concrete and often necessary step to achieving a product goal |
| Additive to all prior Increments and thoroughly verified, ensuring that all Increments work together | Not clear. Arguably there are cases where it would not be additive to all prior increments. Remember, we are running an experiment, and we learn something when an experiment fails, which might not be additive to the eventual product we ship. Meaning, we might learn how not to do something. That does not add to the solution, it prunes a path from the solution tree. |
| To provide value, the Increment must be usable | Frequently in knowledge-acquisition work the resulting artifacts (like the prototypes) might be throw-away. The value is in the knowledge, not necessarily in the artifacts created to acquire the knowledge. So, if we allow “usable” to cover the knowledge we gain, then this Scrum Guide definition statement would apply. If usable means something like the code we wrote to get the knowledge, then many people will conclude it is not usable (assuming we discarded the code as a throw-away prototype). |
| Multiple Increments may be created within a Sprint | Yes, we can perform multiple knowledge-acquisition activities in the same sprint |
| Sum of the Increments is presented at the Sprint Review thus supporting empiricism | Yes, when appropriate, we should present all of our learning |
| May be delivered to stakeholders prior to the end of the Sprint | Yes, we can present (deliver) results from experiments intra-sprint |
| Work cannot be considered part of an Increment unless it meets the Definition of Done | This one is tricky. Most teams focus their definition of done on the customer-deliverable artifacts that they produce (e.g., code). As such, it is very likely that unless the team has a dual-track definition of done (where one track focuses on knowledge-acquisition work), then the knowledge-acquisition work will fail the (deliver-usable-software) definition of done and therefore not be considered part of the increment. |
The goal of this analysis is to illustrate my opinion that the 2020 Scrum Guide definition of Increment does not fully cover the body of work that most teams will perform.
Let’s take an extreme example. What if your team is a “research group?” One of the stated purposes of the 2020 Scrum Guide is to make Scrum more broadly applicable outside of software development, so a research group should be able to use Scrum (and I have worked with research groups in the past that did successfully use Scrum). In such a group the majority of what it does is run experiments to buy information.
For example, you’re a biotech company looking for a COVID-19 vaccine. You might use Scrum and have sprints provide a timeboxed structure for executing one or more experiments. As shown in the table above, your results would not map well to the Scrum Guide definition of an Increment. Should we conclude that this team is not doing Scrum? No, in fact the team might actually be applying Scrum quite effectively to advance forward its vaccine research.
Conclusion
Perhaps a future version of the Scrum Guide will attempt to address this issue. For now, I am happy with the shortening of the name to be just “Increment.” I suggest that practitioners continue to embrace the importance of knowledge-acquisition work in their product backlog. Do what’s practical and don’t be alarmed if you think your work doesn’t lead to an Increment as defined in the Scrum Guide. If the economics favor buying information, then you are doing the right thing!