Skip to main content

When to bring increments to production?

Last post 11:31 am May 6, 2015 by Christian Geyer
7 replies
11:20 am April 21, 2015

I am working as a Product Owner for 4 months - so excuse me for asking the obvious...- and I notice that my team sometimes forgets to bring the finished sprint items to production. My question is: if the purpose of a sprint is to deliver potentially shippable increments and directly after a sprint, the next one starts, when are these the potentially shippable increments brought to production? Or am I to strict here in interpreting the SCRUM guide?


11:08 am April 23, 2015

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.


11:50 am April 23, 2015

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.


03:27 am April 24, 2015

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.


10:01 pm April 25, 2015

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.


11:46 am April 29, 2015

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.


07:59 am April 30, 2015

> 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?


11:31 am May 6, 2015

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.