The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Increment. The glossary has the following description:
Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.
The Increment is one of the artefacts and therefore mandatory parts of the Scrum Framework. Any artefact in Scrum is used to enable transparency about a key control to apply our process control to. We call this empiricism, which is one of the terms I have analysed in a previous article. This means in layman’s terms: We want to measure something to be able to steer based on the measurement. Let’s analyse the Scrum Glossary description and see how the Increment is helping us apply empiricism to our product development.
a piece of working software
In these times you can safely interchange software with product. The core message will remain the same: It needs to work. For whom? The customer. A common misconception is that “working” means as much as working on my personal device that I use for product development. The phrase “But it works on my laptop” is too commonly heard in product development. This does not mean working. I added the nuance of working for the customer because of the variable of the Increment we are actually applying process control to. The steer we want to do based on the Increment will be based on a variable at the customer side. This is commonly referred to as business value. However, I’ve seen more nuanced descriptions like market share, turnover rate, generated revenue, customer satisfaction, NPS-scores, active users per day, etc. Notice how all these variables can only be measured by letting our customer use the Increment. Hence, why working will need to mean as much as working for the customer.
Where will me make that explicit? That’s right, in the Definition of Done, as discussed in our previous article about this term. Which is why we won’t be going any deeper on our analysis on that subject.
that adds to previously created Increments,
Here’s where the benefit of product-based approaches to working start coming into light. By agreeing that we own a product as a Scrum Team and adding to the existent product every Sprint, there’s benefit to be had. Scrum Teams will pertain knowledge about how the product works and what has been built. New requests for features will not mean the organisation will have to launch a new single-function product, but could ask for product teams to add features if this makes sense. This can only happen because we still have development happening for the product, instead of a finished project that is now just being maintained by a run team.
where the sum of all Increments -as a whole – form a product.
I would add the word “previous” right before “Increments” here to ensure what is actually being said here is understood correctly. This does not mean if multiple teams work on a single product that they produce separate Increments every Sprint and need to integrate those. Every Sprint for a single product will produce one Increment only which is indeed the accumulation of all the created work of every team working on the product. If this is one team, we call that an Increment, if it is 10 teams, we call this an Increment as well.
What is actually meant here is that an Increment is always an accumulation of the working product Increment that was created in the previous Sprint with the added on functionality that was built this Sprint. The result of the product development work done in the Sprint is a new Increment, again a working product. This is the whole idea behind Scrum, because the addition we do is based on decision making after measurement is done on the last created Increment. To round back to it being about applying process control: During the Sprint Review the inspectors (Stakeholders & Scrum Team) perform inspection on the Increment and measure agreed on variables like Business Value to make decisions on what to do next. These decisions are recorded in the form of the Product Backlog items and their order, which I will elaborate on in the article discussing the Product Backlog.
The Increment is one of the artefacts in Scrum that are used to perform measurement on as part of a process control approach. They provide the “Transparency” part of the three pillars of Empiricism: “Transparency”, “Inspection” and “Adaptation”. We need this transparency to properly be able to steer on whatever variable we want to steer on in our product development. Often we see this variable not measured from a customer perspective so it’s good to agree on one that we actually can measure with our stakeholders during Sprint Review. To do so enables the Scrum Team, and most notably their Product Owner, to truly apply process control to provide steer on the team’s product development effort.