Releases in Sprints

Hi,

first of all : PO can’t release a sprint ! I probably know what you mean, but I think that we have to be strict in the vocabulary. Second thing is when PO knows that increment is releasable? In my opinion DoD “tells” is it (backlog item) releasable or not. And last but not least Sprint Goal. PO should create clear SG and if it’s reached PO should ASAP release increment to get feedback.

How does the PO specify that a sprint should be released? In a new SB item? In the DoD?

If any further effort must be expended to effect a release, by any party, is the work truly “Done”?

The decision of whether or not to release an increment should be made just-in-time by the Product Owner, taking into account the latest business conditions. Any effort involved in doing so ought to be negligible.

Remember that each Sprint ought to be planned with the expectation that an increment will indeed be released.

Thanks Marcin, Thank Ian

@Marcin you are right in clarifying the words.

I understand better now.

Thanks

Marco

Sprint Backlog items must be releasable, and it's up to the Product Owner to decide whether to release them.

How does the PO specify that a sprint should be released? In a new SB item? In the DoD?

Scrum Guide says "The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment".

What does it mean in practice?

User acceptance testing could be run when items are completed.

When some developers are busy testing, what are the other developers doing?

A sprint activity could be releasing the previous sprint?

I'll try to help a bit:

1. Sprint backlog items should form the increment, increment that should get to a Done state - of potentially releasable quality. Releases usually happen at the end of the sprints, but PO does have authority whether do delay release. 
2. There should be constant cooperation throughout the sprint and the rule is increments are to be released at the end of the sprint. If the PO/business doesn't want the increment released, it must still get to a Done state, but the PO/business must make it clear, as early as possible, the increment is not to be released. Regression tests should always be performed.
3. User acceptance testing is performed as part of "items are completed". You could have a definition of done at story level. So items aren't really completed (done) until acceptance criteria are met.
4. When some developers are busy testing, others can do some refactoring, look into future work (the top of the product backlog), fix outstanding bugs, and so forth. 
5. Releasing the previous sprint can be a sprint taxk (activity) only in those instances where a previous increment was not released to production. In most cases, since releases happen at the end of the sprint, "releasing the previous sprint" should not happen in the new sprint. The new sprint starts fresh. Previous sprint release should've taken place at the end of the previous sprint. And this is only when we're talking about a single release per sprint, for we can also release multiple times each sprint.

And last but not least Sprint Goal. PO should create clear SG and if it’s reached PO should ASAP release increment to get feedback.

Marcin, the sprint goal (SG) should produced through team effort; the PO don't create it themselves. Also, while, as a rule, the increments are released at the end of the sprint, there are cases where the PO may, for various reasons, decide not to release or to release only to a tiny usergroup.

1. Sprint backlog items should form the increment, increment that should get to a Done state - of potentially releasable quality. Releases usually happen at the end of the sprints, but PO does have authority whether do delay release.
2. There should be constant cooperation throughout the sprint and the rule is increments are to be released at the end of the sprint. If the PO/business doesn't want the increment released, it must still get to a Done state, but the PO/business must make it clear, as early as possible, the increment is not to be released. Regression tests should always be performed.

I'd like to clarify here that there's no rule in Scrum that requires a team to release only at the end of a Sprint. I  don't think Eugene meant to say that, but his words could be interpreted as such. A team may also release multiple times per Sprint, even on a daily or hourly basis if the deployment process can handle it and it provides value to the users. There are in fact Scrum Teams with a Definition of Done that includes "released" as a requirement for "done".

I'm saying this because it is a common misconception to think that teams should only release at the end of a sprint. This can lead to dissatisfied users or customers and may also, at times, be simply impractical. Finally, it is a common argument that is used against Scrum by people who have this misconception.

team may also release multiple times per Sprint,

Sorry must disagree as sprint review is required that what was developed is per stakeholder acceptance as well.

1. When some developers are busy testing, others can do some refactoring, look into future work (the top of the product backlog), fix outstanding bugs, and so forth. 

I agree and dev team can be given some free room to play around to be motivated.

I will point out that the Scrum Guide says "potentially releasable increment".  It doesn't say anywhere that it has to be released. 

One thing you learn in the PO cert study is that the decision on whether to release is actually complex.  For example, if the team that develops a cell phone does scrum and they release a new version of the phone every 2 weeks, how do you think the customers and market would react?  No one wants to know that the phone they just bought is obsolete 2 weeks later.  People would quit using that make of phone because of the hassle and devaluation of the product that they own.  Market conditions and the ability of the market to absorb the release are big parts of the decision. 

Sorry must disagree as sprint review is required that what was developed is per stakeholder acceptance as well.

You can release at any point in a sprint.  There is nothing that says it has to be done at the end. And the guide does not say anything about requiring a stakeholder review. 

The Sprint Review's purpose is (from the Scrum Guide)

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed

Doesn't say it is to get stakeholder acceptance.  In fact if you read on in the description of the Review there is nothing said about acceptance. The intent is to have the Scrum Team and the Stakeholders discuss so that the Product Backlog can be adjusted to reflect any changes needed. Try to find anywhere in the Scrum Guide where it mentions getting sign off, acceptance or approval.  It isn't there.  Because if the statement of problem is well written, thoroughly discussed and well understood, there really isn't a need for approval, sign off or acceptance. Satisfying the problem statement to the level that all discussions have agreed to is approval, sign off and acceptance rolled into one. 

One more thing because I didn't see where anyone really discussed this part of the original question.

Scrum Guide says "The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment".

What does it mean in practice?

The way I interpret that and explain it to my teams is that the output of Sprint Planning is the Sprint Backlog and a plan to satisfy the forecasted work. What does that mean?  What ever you want it to.  I coach my teams to see it as having the stories they forecast they can do in the Sprint Backlog and a set of tasks for each story that will enable them to start working on each item.  Notice I didn't say all of the tasks needed to complete the work.  I ask them to do enough to start working on the story and then to introduce tasks as new information is uncovered.  This helps them understand the forecast versions commitment. It also makes them start considering how the work will be accomplished and to prevent them from forecasting more work than they can do based on the information they have at the time of planning.

In the case of a cell phone, the release opportunity might be constrained to selected cohorts of users each Sprint. This would minimize business risk while also enabling empirical validation of the increment.

With other products, such as cloud based services, a release might happen thousands of times every Sprint, if automation can support it. Selected cohorts of users may again be targeted. A Sprint is an ongoing learning experience, and it can be easier to run a small test which provides real data than to try and predict outcomes.

Sorry must disagree as sprint review is required that what was developed is per stakeholder acceptance as well.

I'd argue that the best way for stakeholders to know whether the right thing has been built is if it has been evaluated by actual users.

Here's an article from "Scrum Mythbusters" on that.

The 2017 Scrum Guide Update Webinar had a whole section on that topic. Jeff and Ken discussed how they were working with Scrum Teams in the 1990s that released into production before Sprint Review, with Stakeholders reviewing the thing in production.

The aim of a good Sprint Review should be to inspect the Product Increment and Product Backlog and then adapt the Product Backlog accordingly. It's not a quality gate.

One of the best points is that yea if in definition of done is also released then yea it can be done multiple times per sprint, makes sense. Never did think it that way, thank you, all perspectives above make sense.