Definition of Increment in the new Scrum Guide

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.

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.

My favorite sentence in the new Scrum Guide:

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

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.

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.

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.

Thanks Daniel, that makes sense. 

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"?

@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 :)

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. 

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?

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. 

Hi.

I think this is a bit tricky.

Alexis - when you say element (a for example), is it what has been implemented from a sprint backlog item? That would mean that in increment is what has been implemented from one or more sprint backlog items?

Let us say that we have our first sprint ever. We commit to a sprint goal, we understand why the sprint is important and we plan to work on two backlog items. After some days we have successfully completed working on the first backlog item in our sprint backlog - item a. It meets the definition of done. An increment is born. A day or two before sprint review we also complete work on backlog item b (definition of done is met). At this point - can we determine, without knowing how a and b are related, that do we have one ({a,b}) or two ({a} and {b}) increments?

I think that "The moment a Product Backlog item meets the Definition of Done, an Increment is born." confuses me most. If a third backlog - c - item is done, does it mean that a new increment is born which starts with c, or do you see {a,b,c} as the baby? Or can only {b,c) be a an increment here?

Please enlighten me.

All the work in your Sprint Backlog that supports the single Sprint Goal would eventually combine into a single increment.  After all, you are incrementally building a solution.  Why can't those increment be smaller than just a Sprint?  Consider making a cake.  Each time you add a new ingredient to the mix, you have incrementally come one step closer to finishing the cake.  Same can be said of a Sprint Backlog where each item was refined small. 

This scenario doesn't necessarily apply to all.  There could be a team that takes a single Product Backlog Item into their Sprint Backlog.  Or they could have items refined down to a point where 2-3 items being completed is required before the totality of the work can meet the Definition of Done.  The key in all of this is the statement

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

In my example, item A and B would not meet the Definition of Done until item C is complete.  At that point the combination of the 3 items create an increment. 

Does that help?

I first thought it a bit odd to. Increment for me was the "done" stuff added to the existing product after a sprint. But then I though about it.

If I "increment" by one

i + 1 or even i++ then 1 is what I have "incremented with", but it is not the "increment" itself. Instead the result you have after you have done your incrementing is your "increment". With that follows that an increment will be the result of all previous increments + the the current incremenation.

Hi Tomas,

I would like to know if you still have your question (march '21). 

From my interpretation of the scrum guide, if your definition of done (DoD) isn't too restrictive and allows for your items to be completed (done) quickly without many dependencies , you can have  ({a},  {b} and {c}) increments at the end of your sprint.



However most teams will have some dependency checks in their systems in place and their DoD. (possibly including but not limiting to automated tests ran by a buildserver).

By stating {c} is an increment, it will also usually mean there are no problems with prior increments including the ones in the current sprint.



Also thanks to you all for contributing on this important question regarding an increment and with it defining work that has created value.

For me i think it could be written a bit more clearly in the guide perhaps. 

 The guide talks of 'an increment' i.e. "the moment a PBI is finished an increment in born" and 'the increment' , one would assume this is all the increments of the sprint but there is also mention in the guide of  'increment of value' "No one else tells them how to turn Product Backlog items into Increments of value".  I understand increment is increment; it's a flexible concept but it does lead to confusion.

 Perhaps we would be better to say 'the sprint increment' because we also need to differentiate from the 'product increment' don't we? Though has to remain flexible in scrum; maybe that is the reason Product is not defined in the glossary currently?

So in summary we could have and appear to kind of already have from the guide some glossary changes needed:

1. "Increment" Current glossary definition =Scrum Artifact that defines the complete and valuable work produced by the Developers during a Sprint. The sum of all Increments form a product . 

*the above definition should extend to the sentence "PBI item + definition of done=increment"

** we could separate out this version of increment as "Increment of value" below.

2. "Increment of Value"= PBI item completed against DOD.

2. "Product" The sum of all Increments form a product "

*this maybe incomplete as the sum of all increments in a sprint also forms the increment of a sprint?

3. "Sprint increment" = the sum of all the increments in a sprint and the final increment of the sprint.

*differentiate from Increment No1. above

 I'm sure developers have preferences for clarity around increments regarding version control and already have implemented more granular definitions. 

The morning before taking the PSPO exam i wish i had not have had come accross Alexis's post :-) .