When to bring increments to production?

Hi Martijn,

Scrum does not prescribe how and when to release the increment of product. Once the increment is usable and meets the Scrum Team’s definition of "Done", the Product Owner decides whether or not actually release it. What, when, how or to whom release are technical and business issues.

If in your case, all PBI finished should be released, you can agree to modify the DoD.

Regards.

Each increment is cumulative and so includes all previous increments. This means that work done in a previous increment will, by definition, be made available in any subsequent release.

The decision to release lies with the Product Owner. Each increment should be potentially releasable, with no work left undone. This means that the PO should be in a position to release a delivered increment immediately and without any further dependency on the Development Team.

If the PO decides not to release an increment immediately, and to defer release to a future date, then that is his or her prerogative. However, waste will then be incurred as the value of the increment will be subject to depreciation and any return on investment will be put in delay.

Ian, thanks for your response! You mention that the PO should be in a position to release a delivered increment immediately, without any further dependency on the Development Team. At this moment I am not able to release an increment: I do not have the technical knowledge. Is it advisable for me to learn how to do this; to be able to release using our through Ansible playbooks (which we use in our team)? Or should I delegate this to our developers, or both.. Hope you can tell me your views on this.

You could use any of those approaches. What matters is that you are able to effect a release immediately, so that no business or market opportunity is lost. Some teams use a high level of automation, including feature-flipping, to allow Product Owners to release on demand.

In our case, most teams do not release after every Sprint and the release process is (sadly) not automated. So our Product Owners decide, based on their Product Backlogs, at which points they would like to release. Together with their dev teams they put those "release tasks" into their backlogs, rank & estimate them accordingly and make them part of a Sprint. That way the release "overhead" is part of Sprint Goals and Scopes, making the whole thing transparent and plannable.

> Together with their dev teams they put those "release tasks" into their backlogs,
> rank & estimate them accordingly and make them part of a Sprint.

When are these release tasks planned into a Sprint Backlog? Is it being decided, during Sprint Planning, whether or not to include these tasks? If they aren't included, is it therefore being planned *not* to have a potentially releasable increment by the end of the Sprint?

Ah, good question. What I called "release tasks" is not what is needed to get a potentially releasable increment - they are needed to actually release the increment(s) of one or more Sprints. We still strive to be potentially releasable after each Sprint.

We are in an IT organization and share the systems with many other teams. Those systems have pre-defined release slots and releasing something into those slots still comes with quite some internal overhead. While we are slowly making progress towards improving this, we are still far from great. That is why our POs sometimes decide to skip one such slot because they feel that they do not yet have enough value to warrant the effort of a release.

This was not meant as a good example for handling releases in Scrum; it was meant to share that we do not release after each Sprint and how we handle our (still) non-automated releases.