release many times / sprint goal

The Scrum Guide says: "The moment a Product Backlog item meets the Definition of Done, an Increment is born."

Why would the PO need to give a "green light" for release at all?

Because the PO is the one manages the release . Can the increment be released without the PO agreement ? 

Also increment is the sum of all the pbi in the sprint . Can we have multiple increments within a sprint ? 

So an increment refer to a done PBI or a batch of PBIs? But in a sprint we can have multiple increments ? How can we distinguish the term increment of a done PBI ? 

Why does the Sprint Goal have to be tied to a release?  Couldn't it cover multiple releases?  Couldn't it cover reaching a state where additional value is usable by the customers/stakeholders but there are no plans to release it?  Just because an increment exists does not mean it has to be released.  It can be release if there is a need or a decision by the Scrum Team to do so.  But you can go multiple Sprints without actually releasing anything to Production. 

I am aware that you can release many times per sprint . Thus, this means that every release can happen before the actual sprint goal is reached . 

I'm going to modify that slightly. 

I am aware that you can release many times per sprint . Thus, this means that releases can happen before the actual sprint goal is reached . 

Your revision is somewhat correct depending on how your Sprint Goal is defined.  My revision is true regardless of what your Sprint Goal says. A Sprint Goal does not have to be a release plan. 

It's very important to decouple the concept of the Sprint (along with the Sprint Planning, Sprint Review, and Sprint Retrospective) from the concept of release and deployment.

The Sprint, especially around the Sprint Review, is a period of synchronization between the Scrum Team and the key stakeholders. Some of my leading considerations for how long a Sprint should be are focused around the stakeholders, such as how quickly they are able to use and give feedback on the software, how uncertain or changing their environment is, or how much time they have to spend to synchronize with the Scrum Team.

The release, deployment, and/or enablement of functionality is contextual in nature. Some environments have rules about what must happen before changes can be enacted or enabled. Teams also have to work within their Definition of Done. However, it's not necessary for a Product Owner to "green light" every single change - that would be indicative of continuous delivery or less. If the team is opting to use techniques such as continuous deployment, feature flags, dark launching, or canary deployments, I'd expect that the Product Owner is involved in the discussions as to those being appropriate techniques to satisfy the stakeholders.

Since the Sprint and releasing or deployment are decoupled, there's no reason why a single Product Backlog Item, or even a part of a Product Backlog Item, cannot trigger a release and deployment.

Because the PO is the one manages the release

Why? The Scrum Guide says that the Product Owner manages the Product Backlog and is accountable for value. Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Can the increment be released without the PO agreement ? 

The Product Owner maximizes product value, and does so through collaboration rather than by gated decision making. Why would a Product Owner seek to interpose themselves between an increment of work being Done and released?

Also increment is the sum of all the pbi in the sprint . Can we have multiple increments within a sprint ? 

What does the Scrum Guide say about this?

I knew just before the arrival of the latest guide of scrum that developers own the work to bring a potential releasable increment that po decided just in time depending on market/business conditions and budget whether to release the work increment or not . It is true that in this guide nothing is prohibit the developers to release but what is the truth ? 

It seems like you're referring to this description of the Increment from 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. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The definition of Increment from the 2020 Scrum Guide now reads:

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

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

The wording has changed, but I see almost no changes in meaning. My understanding from some of the discussions around the revision is that a lot of these changes are to clarify the meaning to make it more clear, especially in the software development community, that Scrum supports continuous deployment.

Some people were confused by the 2017 edition, thinking that there was only one Increment produced during a Sprint and that the Increment was only produced at the end of the Sprint and that there was direct involvement by the Product Owner to approve or decide to release the Increment. However, none of these were ever intended to be true.

The 2020 revision makes it more clear that you produce at least one Increment during a Sprint, the team may deliver the Increment(s) at any point in the Sprint, the team and stakeholders review the sum of all of the Done Increments at the Sprint Review. The thing missing is the bit about the Product Owner deciding if the Increment should be released or not, but this is covered elsewhere in the 2020 Scrum Guide, specifically in the description of the Product Owner:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The value of the product cannot be realized until the product is released for use by stakeholders. Therefore, the Product Owner needs to be involved in and accept the risks and benefits of various release strategies. This includes prepared deliveries where the team produces a bundle of one or more changes for potential release, continuous delivery where each change results in a potentially releasable Increment and a member of the team makes the decision if a release is appropriate, or continuous deployment where each change causes a release of an Increment.

I'd also point out that the Product Owner represents all of the stakeholders. The Developers are also stakeholders in the product or service being developed. That means that the Developers should have some insight into what release mechanisms are currently possible and what work is necessary to enable other release mechanisms. A team may not be capable of continuous deployment, or even continuous delivery, until certain preconditions are met. The Product Owner may opt to work with the team to spend time working on these preconditions because having a more rapid delivery mechanism helps to maximize value for future deliveries.

Thank you both ! My post here was mainly due to the fact that I read before that the release is a Just in time decision of the po . There is also a possibility end users not have absorbed the features from the last release thus this CD/CI is not possible . 

hi all,

what about vocabulary in scrum exam?

for instance; to ship / deliver / release an increment, does it mean "create an increment and put on PRODUCTION"? if I found in the scrum exam:

1) The Scrum Team must create a Product Increment at least once in the Sprint; I say YES

2)The Scrum Team must ship/deliver/release a Product Increment at least once in the Sprint; I say NO as I intend delivery on production

3) Scrum can be used to deliver Products multiple times per day; I say YES, as it can be I deliver the increment on production if the scrum team agree

any hints about this topic to avoid language mistakes even if I understand the concept?

Thanks

Flavia

Below are some relevant extracts from the SG: 

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

Each Sprint may be considered a short project.

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.

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

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

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Some thoughts on your example questions: 

1) The Scrum Team must create a Product Increment at least once in the Sprint; I say YES

The SG does not say that the scrum team must create an increment.  It merely says that they are accountable for creating one.  If I had a questions like this I would say false, because they only provide a forecast for each selected PBI, and if for some reason none of the PBIs could be finished before the sprint timebox expired, then there would be no increment.  Also, is the sprint goal becomes obsolete before a single PBI is completed, then you also have no increment. 

2)The Scrum Team must ship/deliver/release a Product Increment at least once in the Sprint; I say NO as I intend delivery on production

Again with the must...  The scrum team do not decide when to release, as that decision is solely up to the PO.  As each sprint should create at least one valuable (usable) increment each sprint, the PO can decide to release that increment if they choose to as it will be in a releasable state due to conforming to its DoD. 

3) Scrum can be used to deliver Products multiple times per day; I say YES, as it can be I deliver the increment on production if the scrum team agree

Your answer to this question contradicts your answer to your second question.  My response to Q2 works for this Q as well. 

Hi scott, I think it is the scrum team who decide when to release not the PO, the SG 2020 shows the scrum team is responsible for all product related activities (page 5)

my doubt was with the term deliver, the scrum guide doesn't mention in details, so I believe it could be in every sense, deliver on prod or whenever according to agreed definition of done. we can deliver one increment or more within the sprint without waiting for Sprint review, but it is important stakeholders inspect it so that we can adapt

based on the above, 2 and 3 are ok to me, I can deliver different increments in the same day, but I am not forced to.

for my previous question #1, I still believe the aim of the sprint is to produce an increment and the scrum team is accountable to produce at least one for each sprint, the sprint cancellation should be outside it (i.e. exceptional)

I have seen some confirmation in this old thread too.

Thanks

Flavia

The PO owns the product, not the scrum team, which is why only the PO can decide when to release the product. 

Yes, the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.  This allows the PO to decide if they wish to release the increment at that point or not.  In order to deliver value to their customers, the PO must release once they decide its time to, as this is the only way to measure value.   

The DoD specifies when a PBI is classed as being Done.  As soon as a single PBI is Done, an increment is born.  The DoD does not state when an increment can be released; however, as it is there to ensure that the increment will be in a Done, and usable state, the PO can decide to release that increment at that point in time (be that during the sprint or at the sprint review, as the sprint review should not be treated as a release gate. 

From The Professional Product Owner book: 

Amazon makes a release every 11.6 seconds.

From the SG concerning cancellation: 

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

How could an increment be USABLE, if it's not released on production? 

I don't get it... 

Someone to clarify this, please? 



Thanks! 

Not all stakeholders are external or production users.  It is possible that an increment can be usable if it enables others to progress.  For example, an usable increment might enable your team to progress to a next stage of development.  An usable increment might be delivered to another team so that they can integrate with your product and thus be delivered into an internal development environment. 

@ Daniel, thanks for those explanations and examples 🙏🏽😊

Thank you so much Scott Anthony Keatinge for providing the clarifications.  I have a follow up doubt to clarify.

The SG says, "An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.".

Q #1:  What does the phrase "delivered to stakeholders" here mean?  Does it mean, deployed/released to production?

Q #2:  If answer to above question #1 is yes, did we not miss reviewing this increment with stakeholders before deploying to production?

Q #3:  If answer to above question #2 is no, and we did have review of completed increment prior to Sprint Review, then in that case, we can exclude reviewing this increment during the sprint review (as its already been reviewed), right?

I really feel this is very confusing!  Scrum should really bring in some clarity here.  The best would be to actually have Sprint review as a gate for production releases.

Often extra questions arise because people are thinking about a software product and you see the increment as releasing a new version.



Imagine your product is not software ... but yoghurt, perfume, a car, ...

Scrum should really bring in some clarity here

The Scrum Guide says: "The moment a Product Backlog item meets the Definition of Done, an Increment is born."

If you're looking for some sort of "gate" for release authorization, that's it. Expecting some sort of benediction and blessing to be given by others would put empiricism in delay, and would also be quite disrespectful of the Developers who have Done the work. 

Hi Anand,

For Q #3...Sprint Review is a review of the Sprint and not just the Increment. Other topics to be discussed include Product Goal and progress towards it, how the Sprint went, updates to market conditions, Product Backlog etc. Having a working Increment in the hands of Stakeholders prior to Sprint Review also means that Stakeholders can share feedback on it as they collaborate with the Scrum Team during the review. 

Looking at the second part of the SG quote you posted "The Sprint Review should never be considered a gate to releasing value." answers your #2 question. There is no stakeholder gate here.