Definition of Increment in the Scrum Guide

It also seems to me that the word "Increment" is used with two different meanings, but I think the wanted definition of increment is [a+b] because under the aspect of continous integration you should not develop an increment [only a] and wait for an integration phase, you should make an inkrement [a&b] that works.

but may someone with more experience can tell us the right meaning of those might controvers definitions.

br,

Hey Philipp,

thanks for your reply.

For me b) does not define that the Increment is "Done" and therefore is in a usable condition (= potentially releaseable).

In the section "Increment" it says: ...the new increment must be "Done"...
a) without b) maps to the sentence above from my point of view.

I still think that a) +b) is the definition for the product. But I am not a native English speaker and therefore maybe I have misunderstood the sentence.

Hogir, Philipp,

think about the basic question: What is your product? After all, that's what we are trying to build, sell and pay our wages with. So is your product a single feature (like the "log in" button on this webpage)? Or is it rather the whole thing (in this case, the whole webpage)? If it is the whole thing: Would you want new features (which you might have paid for) to properly work as well when you visit the webpage or would it be sufficient for you if the old stuff works?

Dear Dominik,

thanks for your input, but unfortunately it did not make things clearer for me. To answer your question: Yes, I want the product always working well. Therefore I want the increment to be "Done" at the end of the sprint so that it can be released.

But I have still the open question about the definition of an Increment within the Scrum Guide.

I have also attached an image to make it clearer what I think the an Increment is:
It would be great if you guys could help me out with the confusion I currently have.

P.S.
I have also looked into different dictionaries for an definition e.g. this definition :

something gained or added

which does not fit to the definition of an increment in the Scrum Guide.
(Src: http://www.merriam-webster.com/dictionary/increment)[IMAGE:15]

An increment isn't the same thing as the product unless it is released. An increment only needs to be *potentially* releasable.

An increment is all prior releases plus the current release. It isn't just the delta increase from a previous release because:

a) The content of prior releases is needed in order for the work done this sprint to have value and to be potentially releasable, and
b) An increment of potentially usable functionality must be tested adequately. This includes regression testing.

Saying that "Each Increment is additive to all prior Increments" isn't a contradiction; the guide is saying that you have to include all prior increments in the current one, which is correct.

Hi Ian,

thanks for your post, it makes the definition for me clear. I understand now better where the definitions is coming from.

The increment in scrum is like the definition, I mean (a+b). I see no problem with the definition of done.

nothing+a = inc 1
a+b = inc1+b = inc2
a+b+c = inc2+c = inc3

All prior increments may be interpreted as the previous increment because they are additive.

My two cents

Hello,

oh.. I'm happy I'm not the only one straggling a bit with this definition ...

Ian , Michael,

Your explanation helped me understand it - thanks.
My only question is where are boundaries of an increment ?
According to good example you have provided Michael:
sum of all done work starting nothing to full product may be called increment or actually it is an increment.
What if I develop my product for 5 years building new features all the time ?

bestR

Just to add to that definition in latest guide says :The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints."

I guess Product Backlog completed in the sprint is considered to be equal to value of the sprint otherwise you could not sum these things together.

> My only question is where are boundaries of an increment ?

There is only one boundary, which is at the closure of the current Sprint.

> What if I develop my product for 5 years building new features all the time ?

By that point you should have delivered 5 years worth of successive incremental value

> I guess Product Backlog completed in the sprint is considered to be equal to value
> of the sprint otherwise you could not sum these things together.

Not quite. It is the value of the completed items from the Sprint Backlog. Items from the Product Backlog that were originally planned into the Sprint only represent a forecast of the deliverables. Additional value may in fact have been delivered, such as unplanned defect fixes.

Ian,

Thanks - This clarifies the idea behind the increment definition.

Thanks Ian for sorting out how Scrum defines a product increment. The reasons behind are clear and really important whether you follow Scrum or not in your agile endeavour.

It seems, however, that this notion is non-intuitive (or simply biased due to prior knowledge). Often I meet practitioners that are very certain that an increment is the delta. Although I personally might accept two definitions it does not really help to persuade people who are transitioning to agile and need a clear understanding of all basic concepts.

Why use a concept of which so many have a different understanding? Why use a concept that is defined different wherever else you read about it?

From general and mathematical definitions, as already mentioned in the thread, an increment is the difference, the added, the delta (http://whatis.techtarget.com/definition/increment, http://dictionary.reference.com/browse/increment).

So, I tried to understand the Scrum definition of (potentially shippable) “product increment” as the delta between two releases. In this case it makes sense that each sprint adds to the product increment that is about to be released. I.e., the product increment is the sum of everything that has been newly built in all the sprints since the last release (but, not sprints prior to the latest release). Of course, the delta must work with and within the whole product and what is already is released must still work (and might have been revised, iteratively). Unfortunately, for me, Ian states that “An increment is all prior releases plus the current release.”. Also, it is not much more intuitive to define product increment as I suggest here either.

Now, what further confuses me is this
1. In the glossary here at scrum.org I find:
“Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole - form a product.” (https://www.scrum.org/Resources/Scrum-Glossary)
As I see it, this is explicitly contradictory to the Scrum guide definition and more in line with the “general understanding”. Or, if you will, in Scrum the product increment is, by definition, the same as the product. This simply does not add up (pun intended).

2. In this video, https://www.youtube.com/watch?v=jTzIHbJjfQE, Ian explains that in a Kanban setting with continuous delivery, the increments become almost invisible and actually “each item itself becomes an increment” (at 2:36). Why is only the released item (that also depend on and must work with the whole that must be regression tested) in Kanban an increment, while in Scrum it is always the whole product and nothing but the whole product? Something is missing here.

So, although I understand the reasons why Scrum defines “increment” as it does, I have difficulties to understand the use of the term “increment” in that way. And more importantly, how do I explain to others why they should accept it (not just by referring to the reasons, because the counter-argument is that the general definitions of increment is different)?

Please enlighten me! :-)

Posted By Johan Natt och Dag on 25 Aug 2015 08:35 AM

So, I tried to understand the Scrum definition of (potentially shippable) “product increment” as the delta between two releases.

+1

In my opinion, an Increment is a delta.

As mentioned, each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

Scrum employs both iterative and incremental development approach.

Unlike prototype development, each iteration, a Sprint, delivers a fully functional increment.

Unlike sub-system or SOA development approach, each increment is built on the VALUE of the increments of all previous Sprints.

The Increment is the sum of all the Product Backlog items completed during a Sprint and the VALUE of the increments of all previous Sprints.

The VALUE includes knowledge-value and customer-value/product-value.

For example, the value of a web reporting functionality delivered at the end of a Sprint may be based on the value of data gathering functionality delivered and the knowledge acquired at previous Sprints.

When the sum of values makes sense to be released, the PO may release it as whole.

> Why is only the released item (that also depend on and must work with
> the whole that must be regression tested) in Kanban an increment, while
> in Scrum it is always the whole product and nothing but the whole product?
> Something is missing here.

Scrum and Kanban treat incremental delivery in different ways. They are different disciplines which address different classes of problem. The term "increment" does not mean, and cannot be expected to mean, the same thing in both of them.

So, in Scrum an increment is not just the delta...it is a summation of the work done in the current sprint and of prior value incrementally attained. In effect, the increment would therefore represent the whole Product should it be released.

In Kanban, there is not necessarily a Product at all. A Kanban might provide value for various services or a combination of products and services. Therefore the concept of an Increment does not necessarily mean the same thing as it does in Scrum. It could be the summation of current and prior value (like Scrum) or it might just be the delta.

The best way to think of an increment in Kanban is as a quantum improvement...i.e. the smallest batch of work which can be actioned and released. This could be either the summation or the delta (you might be able to tell by the regression testing needed). The focus is typically on achieving lean efficiencies, such as better throughput and cycle time. That's a different philosophy to Scrum, where the focus is on maximizing product value.

Thanks for your response!

Ching-Pei: How can the increment at the same time be:
a) the delta between two releases, and
b) the sum of all the value provided by previous sprints PLUS completed items in the last sprint?

Is it the different units? Why then, is there no value produced in the last sprint?

Ian, your explanation of the differences between Scrum and Kanban I get. Also, you stick to the defintion. However, I am still puzzled: Why does Scrum redefine "increment" when in most other situations, especially the scrum.org defintion, "increment" means part or a delta (in one specific unit)?

Briefly speaking, a Increment is a delta but value is accumulative.

The Increment must be integrated to increments have been built to provide the accumulative value.

Think of the 3 three sentences as follows:
1. Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole - form a product.
-- https://www.scrum.org/Resources/Scrum-Glossary

2. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
-- http://scrumguides.org/scrum-guide.html#artifact-transparency-done

3. The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
-- http://scrumguides.org/scrum-guide.html#artifacts-increment

All these make sense without contradiction.

For example, a reporting service Increment delivered at the end of a Sprint must integrated to the ELT Increments delivered at previous Sprints.

The output delivered of the Sprint is a delta functionality, the sum of all the Product Backlog items completed during a Sprint.

The outcome value delivered is not solely create in the Sprint. The accumulative value comes from the Product Backlog items completed at the Sprint plus the value of the features delivered, the knowledge acquired, the architecture and infrastructure implemented at previous Sprints.

Imagine that a reporting service without ETL, its value is definitely limited.
If the reporting service integrated to the ETL functionality, it may provide the optimal accumulative value.
But it not to say the Increment is the sum of the the reporting service and the ETL functionality

“The Increment is the sum of all the Product Backlog items completed during a Sprint and the VALUE of the increments of all previous Sprints.”

What do you think the VALUE means?

Each item on the Product Backlog should represent value that has not yet been incorporated into the Product.

By the end of each Sprint an increment should be available which incorporates some of this value. The PBI's planned into the current Sprint thereby represent a "delta" of potentially releasable value.

The PBI's from earlier Sprints are no longer referenceable, but the value provided by them is residual within the Product. That's the "value" which the Guide is referring to, and which is incrementally accumulated each and every Sprint. Hence in Scrum, an increment is an accumulation of value, and not merely a delta as it might be in a Kanban system.

Hi all, 

just my opinion: 

In dictionary, increment means "amount by which something increases".

I have a daily wage of €100.  My employers e provides an increment of €5, making my Total daily wage= €105. 

Therefore, €105 is not the increment, because if would be the increment, then my Daily wage would be 100+105= €205, which makes my life heaven; however, my employers is probably not going to agree with this definition of increment. 

As far as the Tests go, we must follow scrum guide, which says: increment is existing product + additional features delivered by sprint.

This is however extremely illogical and disturbing. The authors of scrum-guide may want to review the definition of scrum. Just a humble request and contribution from my side. 

Respect and kind regards for all,

Armaghan

Hi all,

according to the scrum guide, the Christmas bonus= Whole years Salary + Christmas bonus!  

I would like to humbly request the authors to update the definition, because all what the dear colleagues and friends are doing is 'defending' the illogical definition, which does not make sense and gives birth to a disorder. 

Respect and kind regards to all,

Armaghan.

Hi Syed,

If you'd like to propose changes to the Scrum Guide, please do so here:
https://scrumguide.uservoice.com/

I think this is another example of splitting hairs when it's not necessary. Per the 2017 Scrum Guide, "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous sprints."

There is no need to further update this definition, in my opinion, it is very clear what the increment is. The increment is both the single increment done during the sprint AND the sum of the increments from previous sprints for this product.

+1 Curtis.

Syed, the Scrum Guide does not state that an increment is the product plus the improvements to it.   You may be misunderstanding both the definition of increment, and what is stated in the Scrum Guide.

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints.

It just means that...your increment better work with what you have developed so far. The phrase "..and all previous Sprints." emphasizes on the fact that you have to also integrate your Sprint work with the previous work done so far.