Code Deployment

Each Sprint must deliver a potentially releasable increment to the Product Owner. The matter of release is therefore orthogonal to the work done in the corresponding Sprint, and is at the discretion of the PO.

Note that this does not preclude the possibility of making a release, or indeed multiple releases, during the Sprint itself. Also, there's nothing to stop the Development Team from making the deployments if both they and the PO are willing to support that arrangement. The important thing is that, even when something like continuous deployment into live is in force, the PO has ultimate control over each release configuration and can therefore account for the Return On Investment each one yields.

Hi Abhijit,
deployment is not part of Scrum, because Scrum is a framework for developing products, not for delivering them.
This means, the deployment in production happens whenever the Product Owner feels like it. Usually he will decide this after the review, because then the product increment is transparent to him.
The retrospective takes place directly after the review. Again, deployment is not part of Scrum and should be decoupled from the Scrum events in order not to become an impediment.

Thanks Mitchel and Ludwig.. In similar lines, this is a typical question with options..

When should the Product Owner ship or implement a Sprint increment?
A. At the end of every Sprint.
B. When the Team feels is done with every Sprint.
C. Whenever the increment is free of defects.
D. When it makes sense.

My pick is Answer D..

What would you guys feel?

My answer would be D too.

A - It's not necessary to release the increment. I can be done, but it's not mandatory.
B - It's up to the team to provide a possibly releasable increment but the team doens't get to decide when to actually release it. That's up to the PO.
C - The increment should be potentially releaseable. Your definition of done should say that it's free of known defects. TDD should help in that.
D - When it makes sense to the PO, he/she can release an increment whenever he/she feels like it. Seems like the most logical answer.

HOWEVER:
In some (most?) environments, the people who work on the increment (Development team) will also be the ones that release it.
Releasing software takes time and preparation.
So if the PO decides to release it, one or more people on the team will invest time in it.
This will affect the velocity of the team during the sprint.
How should one handle that?

> Releasing software takes time and preparation.
> So if the PO decides to release it, one or more people on the team will invest time in it.
> This will affect the velocity of the team during the sprint.
> How should one handle that?

Each increment *must* be potentially releasable. If sufficient time has not been spent in preparing for release, then the potential for doing so can't be there, and the Definition of Done is either inadequate or is being improperly applied. With a good DoD, if the PO decides to release then the implementation of that decision should take negligible time.

The original question is a bit harder that one might suppose, because both A and D are valid answers. A is valid because a PO should not negotiate a sprint backlog or goal without release being the aim. The PO *should* therefore release at the end of every sprint, even if it is not mandatory to do so. Remember that in Lean terms, a failure to release increases batch sizes and the depreciation of stock-on-hand.

However, if we are limited to one answer only, then D is certainly the best. A PO should never release if it doesn't make sense to do so.

D. When it makes sense.