Misconceptions about increments
Considering a question I came across in the Free Scrum Master Pratice Exam as well as a rather old thread on this topic, I got the feeling there is a general misconception about what an increment is. In the practice exam, the expected answer is: "The sum of the Done work during a sprint, plus the work Done in earlier sprints."
In math as well as in natural language, an increment is the amount of increase and not the result of incrementing (see, for example, Merriam-Webster or Collins).
Refering to the examples and notation in the mentioned thread, let {a, b, c} be the current state of the product and {a, b, c, d} the state after the next increment. In my opinion it is misleading to call {a, b, c} and {a, b, c, d} increments. These are states of the product stemming from the increments a, b, c, and d. I also would refrain from thinking of increments as product backlog items. An increment is just a usable, Done, value providing stepping stone towards the product goal. This may be a completed product backlog item (as mentioned in the Scrum Guide) but I would also consider, for example, a bug fix (which may even be unanticipated during the planning) a possible increment. "The moment a Product Backlog item meets the Definition of Done, an Increment is born", but not vice versa.
That notion of an increment should also solve some of the problems discussed in the mentioned thread. For example, it becomes clear why in the Sprint Review a sum of increments (boiling down to all Done changes that have occurred since the sprint started) is presented. It also becomes obvious that these changes may overlap (e.g., a change in increment a may later be overriden or deleted in f).
I assume, the wording in the Scrum Guide "Each Increment is additive to all prior Increments ..." causes this misconception. People seem to interpret additive here in the sense that an increment contains all prior work (as implied by the second definition on Merriam-Webster). I am quite sure, however, the third definition fits much better; the increments are additive in that their effects together form the product.
Feel free to correct me if I am off track. Either way, adapting the wording of that last sentence in future versions of the Scrum Guide might be helpful to avoid confusion.
It's best not to think of an increment as a thing, but as the reification of a valuable experiment. Lessons are learned, empirically, through the usage of previous increments. These learnings are subsequently brought forward each time a future experiment for the Product is run.
What is wrong with thinking of increments as additive. Taking your example of A, B, C, D. I see multiple combinations that could be delivered, i.e. A+B, A+C, A+d, B+C, etc. However, each individual increment has to be capable of being used, reviewed by stakeholders and valuable to them. This would allow each increment to be delivered individually as well.
In math as well as in natural language, an increment is the amount of increase and not the result of incrementing
Absolutely correct and both A, c are increases however, there is nothing to say that c has to be an increase of a. It could be an increase based upon the same starting point used by the increment of a. In math, an increment has a starting and ending point. Again using the A, B, C, D thing in math.
- A = 2,
- B = 1.75,
- C = 5,
- D = .275.
Think of how each of these increments could be completely different but when accumulated, the result is even more. Now, assume software development of a user profile management system.
- A = Ability to add one or more pictures to the profile,
- B = Enter and validate US ZIP Code + 3 format to profile
- C = Ability to specify locale information for personalization of text, measurements, etc in the profile
- D = Add "Dr." to drop down menu of salutations in the profile.
Each of these provides value on it's own, should be able to be delivered individually, reviewed by stakeholders and is an amount of increase of functionality. But when combined with 1 or more of the others provide even more "incremental" value from what is available to the user.
Remember that Scrum does not say anything about when an increment is to be delivered to the end user for use. It says that one or more increments must be created in every Sprint. So creating any work that satisfies the Definition of Done during the Sprint satisfies that.
I think the simple way to see this is that the increment is nothing but the product and, in every sprint, there is a value addition that takes place, and your overall product value also increases (so it is additive). If you add some new feature during the sprint and it breaks some already existing feature of the product, then that is an issue.
The word might be confusing but think of it as a product increment (existing product + value addition brought by the sprint deliverables).
I realize that I should have added more context. I am not struggling with understanding the intentions. I am more concerned with precision and unambiguity. I stumbled across the aforementioned thread and the question of the pratice exam because I am preparing for the PSM exam. My above lines are written from the perspective of an aspirant realizing that the expected answer to a possible question of the exam might be different depending on whom you ask. And that's definetly something you don't want to fail for, in the worst case.
What is wrong with thinking of increments as additive.
Nothing, if the word is interpreted as you did in your example, i.e., you can add increments together to form a more complex whole. But I am having a hard time calling a sum of increments an increment again, up to the point where the current product is referred to as an increment. While it might technically be correct (if we consider the kick-off as the reference start point of incrementing), I would not consider using the same term for two (at least semantically) different things a good practice.
"The sum of the Increments is presented at the Sprint Review thus supporting empiricism." - Scrum Guide
This clearly refers to the delta, the changes that happened during the sprint. I doubt anyone would present the whole product over and over again. From the guide, "Each Increment is additive to all prior Increments..." also strongly suggests that we are talking about additive changes. Exactly as you pointed out in your example, Daniel.
Still, I read "An increment is... the sum of the Done work during a sprint, plus the work Done in earlier sprints.". Not only in the practice exam but also, for example, at ScrumAlliance. At least, they rename it to product increment there which may also be a hint that something isn't completely right.
Bare with me if all of this sounds pedantic. Ultimately, it's just a single question, right?! But with precision comes clarity. And improving in small steps is at the heart of being agile. That's what I'm here for.
Incremental learning isn't really about having a delta. The aim of incremental learning is for the learning model to adapt to new data without forgetting its existing knowledge.
I doubt anyone would present the whole product over and over again
That is right the demonstration during the sprint review will show only the new features added during the sprint. But the team must ensure that regression testing is done (in each sprint) so that new features do not break already existing ones. Hence it is best that you think that what you deliver is the product increment and not just the delta.
I like this description from Scrum.org’s learning series on The Increment: https://www.scrum.org/learning-series/increment/…
The Increment is the latest version of the product that conforms to the Definition of Done.
Stefan, I think this aligns to something you said earlier…
the increments are additive in that their effects together form the product
I think “effects together form the product” is a good way to think about it, though it might not always be additive. We may also take away from the product, with an example being to remove an unused feature.
Chuck Suscheck also has a great video where he explains this really well using whiteboard markers: https://www.scrum.org/resources/what-product-increment