what is a usable increment?

The Increment doesn't have to be released to be usable. The definition of "usable" is "able or fit to be used". The intention is that at least one usable Increment is produced during each Sprint, meaning that if the Increment were to be released, it would be fit for use by the end-users of the product.

Can you explain how an increment can be usable without releasing?

for an increment to be fit to be used it must be available for the user so it must be released. 

The way i read the Scrum guide it states " at least one usable Increment is produced during each Sprint" meaning you have to deliver value at least once per sprint. so my conclusion would still be that you at least release once per sprint.

Where is my thought proces wrong?

Even if users can't use it, the Increment can be in a usable state. It can be fit for use and that fitness can be demonstrated without it actually being used. Fitness for use is about asking if the product, in its current state, would be useful and valuable if it were to be put in the hands of users.

I'm not sure what domain you are working in, but I come from a background in software. I can demonstrate the fitness for use in a testing, sandbox, or pre-production environment and let the Product Owner or stakeholders decide when it is appropriate to deploy to production. One consideration could be if the value of the usable changes outweigh the cost of making those changes available to the end-users - if you have a more costly release and deployment process, you may only deploy changes to production once every couple of months. However, if you have a robust continuous integration and continuous delivery pipeline, the cost for deploying changes may be incredibly low and every change may be deployed.

" Even if users can't use it, the Increment can be in a usable state. It can be fit for use and that fitness can be demonstrated without it actually being used. Fitness for use is about asking if the product, in its current state, would be useful and valuable if it were to be put in the hands of users" 

They way you put, it looks to me is delaying value. to me the increment is only valuable after it is put in the hand of the user.

"Let the Product Owner or stakeholders decide when it is appropriate to deploy to production." Did the product owner not already decide this when he agreed on the sprint goal at the start of the sprint?

They way you put, it looks to me is delaying value. to me the increment is only valuable after it is put in the hand of the user.

I don't agree with that. There's a difference between having a valuable Increment and delivering value. You can demonstrate the value of an Increment without delivering that value. When the cost of putting an Increment into the hands of a user is high, there is great value in obtaining feedback on the Increment to ensure that what you hope to put into the hands of the user will be valuable.

"Let the Product Owner or stakeholders decide when it is appropriate to deploy to production." Did the product owner not already decide this when he agreed on the sprint goal at the start of the sprint?

No, not at all. The Sprint Goal is the objective for the Sprint. It has nothing to do with delivery. Nothing says that the Scrum Team has to deliver the Increment into the hands of the user at the end of every Iteration. However, by the Sprint Review, there must be an Increment that is appropriate and fit for handing over to the user for inspection.

No, not at all. The Sprint Goal is the objective for the Sprint. It has nothing to do with delivery. Nothing says that the Scrum Team has to deliver the Increment into the hands of the user at the end of every Iteration. However, by the Sprint Review, there must be an Increment that is appropriate and fit for handing over to the user for inspection

I don't agree the sprint guide states it has to deliver value each sprint. The sprint review is there to inspect if this value has been delivered and what progress has been made to the product goal and what todo next.

I don't agree the sprint guide states it has to deliver value each sprint.

Please quote the section of the Scrum Guide that says this. I could not find any mention of delivering value.

There are a few quotes, though:

The Scrum Team turns a selection of the work into an Increment of value during a Sprint

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Sprints are the heartbeat of Scrum, where ideas are turned into value.

In order to provide value, the Increment must be usable.

The Scrum Team must produce an Increment that is valuable, but it says nothing about actually delivering value to stakeholders. It doesn't even make sense to deliver value that is less than the cost of performing the delivery.

Let me jump in with an example.

Product Goal

• Add a new view that lists out data in a table view that will allow the users to sort/filter on various columns.  The data in the view come from multiple places within the DB and it has never been aggregated in this manner.  

Work breakdown

• Create a performant query that will aggregate the data
• Create a view that will render the data from the query
• Implement filtering capabilities
• Implement sorting capabilities

The query on its own would not be something you release but it is usable by the organization to complete the work. The view could be released without any of the filtering and sorting capability in order to get feedback on the layout.  The filtering and sorting capabilities would each be releasable on their own.  But as a Product Owner you might choose to wait to release this to the entire customer base until the full functionality is in place.  You might want to do some kind of limited release or beta with the incremental progress.

Hope this helps.

The must be usable implies for me that it is released! Because a not released increment is not usable.

That sounds like a barrier would have to be negotiated (an act of release) before usage. Is that barrier helpful? I'd suggest it is only really necessary that the work is Done.

Hi @Sven Lankreijer - In addition to the above valid points, please note that releases are always on customer demand. By your logic, it seems like you're tying the 'release of valuable software' to a particular cadence from your side - which is at the end of every Sprint. The only cadence that a Scrum team should follow is that of a Sprint. Let the customer and the Product Owner discuss and agree upon the release schedules.

On a slightly different note, in Product Management parlance, there is often misconceptions about 'cost of delay', wherein people are always bent towards pushing usable increments to Production as soon as possible. That is not correct - the logic of 'cost of delay' works both ways - releasing too early also incurs cost.

Therefore, the Scrum team should concern itself to creating a 'usable' increment at the end of every Sprint which satisfies the definition of done and the acceptance criteria of that particular item - may be in a Test or Pre-Production environment. It would  then be up to the Product Owner to discuss with the customers and come up with a release schedule at the 'opportune moment'.

So, develop on cadence & release on demand! 

I am still struggling to match the feedback with the 2020 scum guide. In the scrum guide there is no longer a statement about the decision to release by the product owner. The way I now interpret the usable increment is: The PBI is available for use by the intended user of the PBI. in the example of Daniel's PBI

• Create a performant query that will aggregate the data 
  • Internal user 
• Create a view that will render the data from the query
  • can be internal or external user 
• Implement filtering capabilities
  • external user
• Implement sorting capabilities
  • external user

I think that the with the changes that are made in the 2020 scum guide the tollgate of releasing value was removed because it was holding back the delivery of value.

If i look at Soomyadeep's comment about cost of delay and releasing to early. hasn't the scrum developed the wrong PBI? weren't there PBI that could have been developed and be in the hand of the user that would have given value?

And can a PBI not delivered to the user be called done? As there ar activities to be done to get it to the users. and the scrum team is also responsible for these activities!

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. 

I know in real-life this is not how it works in a lot of cases. 

As I tried to illustrate sometimes an increment can be valuable and released internally.  The people/applications that use an internal resource are also customers/stakeholders. At times those internal users/stakeholders could be members of the team delivering the increment. 

As a Product Owner you are accountable for maximizing the value that the Developers produce. You play a part in determining whether something is valuable enough to release to users/stakeholders.  Stop thinking about "release" only being external and consider the incremental value that can be released to anyone needing the functionality. 

This comes from the current Scrum Guide section that describes the Definition of Done

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Your Definition of Done is used to gauge if something is ready for release. However that doesn't mean is has to be released or even that it is released unless that is specifically stated in your Definition of Done. But if that was the case, then you would never discuss anything in a Sprint Review that isn't already delivered to Production. The purpose of the  Sprint Review is for inspecting, discussing and adapting in order to deliver the correct value to the stakeholders. Some of the time that is to prevent something that was misunderstood from releasing or to adapt to new requirements that would make the current work not as valuable. 

As you stated there can be other activities that have to occur for releases. Some of those might be done by individuals external to the Scrum Team such as Marketing, Public Relations, Legal.  So the Scrum Team determines if something is able to be released and provide value.  There may be further rules that have to be followed before something is actually released.  The statement you quoted states the the Scrum Team is responsible. The Scrum Team also includes the Product Owner role so the individual fulfilling that role might have activities they have to do after the increment is "done".  

The burden of determining when something releases has changed in today's world.  Take the example of Continuous Integration/Continuous Deployment (CI/CD).  In that model if the code changes pass a series of established criteria it is automatically released to Production.  In those models, the Scrum framework would suggest that the Definition of Done include all criteria and gates that have to be fulfilled before it can be released.  As much of those criteria and gates that can be automated should be.  The Product Owner, as part of the Scrum Team, would determine how the Definition of Done would be stated in order for this to take place. 

The purpose of the  Sprint Review is for inspecting, discussing and adapting in order to deliver the correct value to the stakeholders. Some of the time that is to prevent something that was misunderstood from releasing or to adapt to new requirements that would make the current work not as valuable.

this sounds like you are using the sprint review as a gate for releasing. where my interpretation of the purpose of the sprint review is to inspect the progress to the product goal by inspecting the outcome of the sprint. and see what we learned and adapt the product backlog so we can maximize value in the next sprint.

and yes my opinion is that you should try to deliver increments as often as you think it delivers value.

And yes Continuous Integration/Continuous Deployment (CI/CD) is a good practice for doing this.

As you stated there can be other activities that have to occur for releases. Some of those might be done by individuals external to the Scrum Team such as Marketing, Public Relations, Legal.  So the Scrum Team determines if something is able to be released and provide value.  There may be further rules that have to be followed before something is actually released.

I would try to work with the individuals external to the scrum team to comply to the further rules during the sprint.

and if there is high cost for getting increments delivered to the users as a product owner i would put a item on the backlog to investigate how to lower these cost and make it easier to deliver

Interesting discussion.

Just to add, there has been a small but significant change in terminology between the 2017 and 2020 Scrum Guides.

The 2017 Scrum Guide states that:

"The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint."

This phrase "potentially releasable" appears five times in the 2017 guide but has been removed from the 2020 guide. I think this may account for some confusion.

this sounds like you are using the sprint review as a gate for releasing. where my interpretation of the purpose of the sprint review is to inspect the progress to the product goal by inspecting the outcome of the sprint. and see what we learned and adapt the product backlog so we can maximize value in the next sprint.

You are correct and i'm not using it as a gate. Wouldn't you say that as a result of the inspection that occurs during the Sprint Review, the Scrum Team may decide not to release the increment created?  Isn't that just as likely as deciding that it should be released?  The key is that the decision is made based upon the inspection that occurs throughout the Sprint and that the Sprint Review is just one of those opportunities.

I think the key to your confusion is this statement from your original post

The must be usable implies for me that it is released! Because a not released increment is not usable.

You equate usable to mean released.  In my previous posts I tried to illustrate that usable and released do not have to be equated.  I apparently did not do a good job of that.  An increment could be usable to the team.  If it is an incremental stepping stone towards the functionality that the Product Owner wants to provide to the consuming public. Wouldn't you say that is usable?

You equate usable to mean released.  In my previous posts I tried to illustrate that usable and released do not have to be equated.  I apparently did not do a good job of that.  An increment could be usable to the teamIf it is an incremental stepping stone towards the functionality that the Product Owner wants to provide to the consuming public. Wouldn't you say that is usable?

You did a good job explaining it that to me and i agree with you on that point. 

Wouldn't you say that as a result of the inspection that occurs during the Sprint Review, the Scrum Team may decide not to release the increment created?  Isn't that just as likely as deciding that it should be released?  The key is that the decision is made based upon the inspection that occurs throughout the Sprint and that the Sprint Review is just one of those opportunities.

I disagree with you on this part. I interpet the scrum guide to not use the sprint review to decide to release or not release. but could agree with you that this could be a opportunity to adapt and not releases. But the risk is that the sprint review is used as a gate for releasing and i see this a lot in real life and that is not the purpose of the sprint review

@Sven Lankreijer Yes, it is a risk that Sprint Review may be used as a gate for release, IMHO it is the reason why we can find this statement in the Scrum Guide:

(...) The Sprint Review should never be considered a gate to releasing value.

Nevertheless, echoing previous points, having a usable Increment is not equal to releasing it, however, it is a context heavy topic, so maybe in your context, it is equal. I like to use thought exercises, what do you think is closer to the truth in i.e development of the next iPhone version:

• a) Iteration lasts one year, and there is one usable Increment created, as it is released once per year.
• b) There are many iterations and usable Increments created, however, there is only once per year release (of value).

I would say, that in line with the Scrum spirit would be to think about this topic like this: If it happens that throughout the Sprint we do not decide to either release Increment, then the Sprint Review is the last suitable formal event within the Sprint to ask ourselves this question and think for a while about releasing the Increment.

(...) Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.

As long as it won't be a routine and default behaviour, and you can find that people involved actively consider and release Increments regardless of the Sprint Review occurrence, it should not be alarming too much.

I would like to thank everyone that contributed to this forum topic it gave me a deeper understanding of what a usable increment is.

And helped my pass my PSPO II exam.

I will start preparing for PSPO III now. and will probably use the forum again for similar discussions and hope to draw from the community knowledge again.