Definition of Increment in the new Scrum Guide

Last post 09:25 pm January 9, 2021
by Daniel Wilhite
12 replies
Author
Messages
07:51 pm December 27, 2020

I'm a little confused about the definition of increment in the new Scrum Guide. I've always thought of each increment as the latest integrated and done code, which includes everything that is done by that time, and the code that would be released to the end users if we decide so. However, when I read "The sum of the Increments is presented at the Sprint Review" in the new guide, I start wondering maybe it refers to subsets of the whole product (or its different branches) as increments, because otherwise, it could have said, "the latest increment is presented at the Sprint Review". What's the exact definition of increment?

09:39 pm December 27, 2020

Multiple Increments may be created within a Sprint, each inspectable and potentially releasable in its own right. The Sprint Review is not a gate for such things.

Nevertheless, the Sprint Review is a formal opportunity to inspect the totality of work Done that Sprint, and for the Product Backlog to be adapted to better reflect the work that is understood to remain.

Hence it is more correct to say that the sum of the Increments is presented at the Sprint Review, rather than the latest Increment.

12:37 am December 28, 2020

The Scrum Guide does clarify that

Each Increment is additive to all prior Increments…

and

Work cannot be considered part of an Increment unless it meets the Definition of Done.

So this should rule out multiple concurrent or competing Increments.

To me, it sounds like an attempt to explain that a Scrum Team needn't constrain itself to producing or releasing only one Increment per sprint, and that the changes from each of these Increments should be available for inspection at the Sprint Review.

01:16 am December 28, 2020

My favorite sentence in the new Scrum Guide:

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

08:49 am December 28, 2020

Thanks for the replies. 

I know that the guide wants to emphasize the correct release/increment/sprint relationship, but my issue with the definition of increment is different. 

The way I see it (or used to see it) is this: Let's say we're at the beginning of the 8th Sprint, and our latest Increment is this:

I7 = { a, b, c, d, e, f }

Which means that it contains elements a, b, c, d, e, and f. We start working on a new item called g. After a while, it's fully done, and when added to I7, would turn it into a new done Increment according to the definition of done: 

I8-1 = { a, b, c, d, e, f, g }

Three days later, h and i are completely done, at the same time; therefore: 

I8-2 = { a, b, c, d, e, f, g, h, i }

And close to the end of the Sprint, j is finished: 

I8-3 = { a, b, c, d, e, f, g, h, i, j }

The team was also working on k and l, but they couldn't finish them by the end of the Sprint, and therefore, those go back to the product backlog and not the increment. 

Now it's time for the Sprint Review meeting. What is the increment we'd show to the stakeholders? If the above scenario is what the Scrum Guide means, then what we'd show them is the latest increment (I8-3). Of course, we can consider the sum of all increments (I8-3 + I8-2 + I8-1 + I7 + ...), but that would be the same as I8-3, and therefore, there's no need to say the sum of increments when we can simply say the latest increment. As a result, I have some doubts that maybe the scenario I've described above is not compatible with the new Scrum Guide and it has something in mind that won't exist in the latest increment and we have to add up all the increments. Is it so? Can someone give me an example or scenario in which the latest increment is different from the sum of all increments?

The only thing I can think of, is for developers to work on multiple branches during the sprint, and have increments like the following: 

I8b-1 = { a, b, c, d, e, f, g }

I8b-2 = { a, b, c, d, e, f, h, i }

I8b-3 = { a, b, c, d, e, f, j }

Then, those branches are merged into one and create the following at the end of the sprint: 

I8 = { a, b, c, d, e, f, g, h, i, j }

Which can be referred to as the sum of the previous increments. However, I'm not comfortable considering I8b-1, I8b-2, and I8b-3 increments, because as long as they are not merged into one, I can't consider them fully done, as no one can be sure what's going to happen when they are merged, and some extra work may be required.

05:38 pm December 28, 2020

In my opinion everything in your formulas are correct but there is another possibility that you are not considering. Sometimes you might deliver a short term or partial solution in an increment that would be later made unnecessary.  What if in your formula "g" makes "b" obsolete or unnecessary.  In that case your increment would be I9 = {a, c, d, e, f, g, h, i, j}.  The key is that the latest increment contains all of the work that makes up the solution that can be delivered to the stakeholders and not all of the work that has been done. In this case the Sprint Review may include the team elaborating on what was removed and what replaced it as the inspection and adaption of the Product Backlog is performed.

10:53 pm December 28, 2020

The only thing I can think of, is for developers to work on multiple branches during the sprint, and have increments like the following: 

I8b-1 = { a, b, c, d, e, f, g }

I8b-2 = { a, b, c, d, e, f, h, i }

I8b-3 = { a, b, c, d, e, f, j }

Those are surely not Increments, as "Work cannot be considered part of an Increment unless it meets the Definition of Done." and it makes absolutely no sense to consider something as "Done" if competing branches can inadvertently remove capability from a prior Increment.
In that sense, Increments are linear.

It's easy to get wrapped up with the wording here, but I think it's pretty clear the intention is to not inhibit releases, nor the inspection and adaptation of those releases.

The key is that the latest increment contains all of the work that makes up the solution that can be delivered to the stakeholders and not all of the work that has been done. In this case the Sprint Review may include the team elaborating on what was removed and what replaced it as the inspection and adaption of the Product Backlog is performed.

To build on this, particularly if Scrum Teams have an outcome-oriented Sprint Goal, this might be a routine occurrence, as experiments are conducted, lessons learned throughout the Sprint, and frequent iterations made to deliver value as early as possible, maximize learnings constantly, and change plan when sensible.

09:07 pm December 29, 2020

Thanks Daniel, that makes sense. 

08:11 pm January 8, 2021

I just saw this: https://www.scrum.org/resources/scrum-glossary

Where it defines Increment as follows: "Scrum Artifact that defines the complete and valuable work produced by the Development Team during a Sprint. The sum of all Increments form a product."

What I understand from the last sentence is not compatible with the conversations we've had here. It seems to mean that Increment is not a cumulative concept. Daniel, even the scenario that you described doesn't apply here, because a team may want to demonstrate features that they created and removed in a single Sprint, but when it comes to the product, the items that were removed cannot be considered part of it. So, why does it say "the sum of all Increments form a product" instead of something like "each Increment is the latest version of the product"?

09:39 pm January 8, 2021

@Alexis Leroy let's examin current Scrum Guide.

An Increment is a concrete stepping stone toward the Product Goal. (...)

It is not about features, or functionalities per se, but about Product Goal, or sum of Goals, in the long term:

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

We can read in the Scrum Guide that:

Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.

An simplified example of addition that removes features which you mentioned above can be an equation: 2 + (-1) = 1 😉

We should also refresh part about the Sprint Review, notice that there is no mention of the Increment, it is more general:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

Consider this example:

Some years ago Samsung had in their smartphones an IR and pulse sensors, now they get rid of them, so can we say that i.e. "5 Increments ago our smartphone (product) had pulse srnsor, now summing all of our Increments our smartphone have no pulse sensor, hovewer we can highlight multi-lenses camera module that takes its place."

IMHO this glossary description that you quoted above does not contradicts what Daniel said. Sum of the Increments form a product, and you still can have Increments that removes items from product, even if we will not consider removed items as part of product, you still can inspect that during the Sprint Review, imagine below simplified scenario:

Product Goal: Make our smartphone more affordable for customers

Sprint Goal: Remove features that have low usage adoption

Result of our work: Smartphone without pulse and IR sensor

Outcome: lower cost of production and maintenance of our smartphone

Next (potential) step / Sprint Goal: Removing Iris scanner / Improving face recognition to reduce number of front facing sensors

All of the above is needed to ensure proper transparency and inspection during the Sprint Review. Depending on context and time you may review a product that sum of increments strip out of some features. Knowing the previous state of the product, the Product Goal, the Sprint Goal and current state that is result of your Increments and their outcome(s) enables you to Inspect in some degree even items that are no longer part of the product.

Hope this help :)

09:41 pm January 8, 2021

If you want to show your work on the math my scenario it is actually 

I7 = { a, b, c, d, e, f }

l8 = { a, b, c, d, e, f } + { g, h, i, j }

I8 = { a, b, c, d, e, f, g, h, i, j }

=============

I9 = l8 - { b } 

l9 = { a, c, d, e, f, g, h, i, j }

In that case the sum of all increments form a product.  My scenario still stands where you can discuss that part that was removed in order to arrive at the current increment. 

10:52 pm January 8, 2021

Well, my primary purpose was to make sure that my understanding of what Scrum considers to be the 'increment' is correct, which seems to be okay. However, Daniel, you explained why that statement is not wrong, but you didn't say why it was necessary to have such a statement instead of a simple one.

In our previous conversation above, your scenario was about a particular case where the simple statement may not work well for sprint reviews, but now, it's not doing the same for the description of 'product'. Does it?

09:25 pm January 9, 2021

To be completely honest, I have always viewed the current increment as the latest version of the product although it might not be the current released version.

Since Scrum is a framework for incremental delivery of a product it has never occurred to me to be any other way.