Skip to main content

Production release cadence as relates to Sprint cycle

Last post 05:28 pm January 29, 2019 by Daniel Wilhite
3 replies
05:26 pm January 28, 2019

Hi everyone,

I have seen situations where different teams use different production release cycles, and is not in consistent cadence with Sprint cycles (eg: production release every 2 or 3 sprints). Several teams also go multiple years before any production release, yet continuing to work in Sprints for those years. Other teams release to production at the end of every 4 Sprint (with Continuous integration, Automated testing or continuous delivery/deployment) with all manual efforts of testing, integration and deployment, which to me is running mini-waterfall projects in disguise of Sprints.

Scrum guide does not seem to recommend any cadence or relation of production releases with Sprints, which makes sense, because teams and product owners can choose when they are ready and want to as long as it is shippable by end of Sprint.

Is there any industry standard or most recommended approach for any sort of relation of production release cadence with Sprint cycles or even at a regular cadence? (I understand hiccups happen, and sometimes hotfixes might need to be applied outside of a cadence).


09:19 pm January 28, 2019

Release ought to be a just-in-time decision made in response to clear demand signals. There may be multiple such opportunities during a Sprint, for example. The deliberate batching of work into longer release cycles (e.g. a new version every 3 or 6 months) helps predictive planning by stakeholders who are not themselves attuned to more agile ways of working. Therefore release-on-cadence, although common, can be seen as a bit of a crutch.


03:46 pm January 29, 2019

I have seen situations where different teams use different production release cycles, and is not in consistent cadence with Sprint cycles (eg: production release every 2 or 3 sprints). Several teams also go multiple years before any production release, yet continuing to work in Sprints for those years.

I think they didn't get the memo :) ... Working software over comprehensive documentation > Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale & Working software is the primary measure of progress.

The PO can of course decide not to release every sprint, but that's another story.

 

Other teams release to production at the end of every 4 Sprint (with Continuous integration, Automated testing or continuous delivery/deployment) with all manual efforts of testing, integration and deployment, which to me is running mini-waterfall projects in disguise of Sprints.

If there is a single release each sprint, within a max. 4 weeks timeframe, there are no issues as long as work flows throughtout the sprint (as in, NOT artificially dedicate 2 weeks for development, followed by 1 week story testing, followed by 1 week bug fixing / regression).

 

Is there any industry standard or most recommended approach for any sort of relation of production release cadence with Sprint cycles or even at a regular cadence? (I understand hiccups happen, and sometimes hotfixes might need to be applied outside of a cadence).

There is one (sort of :) ): release as often as you can, as long as you deliver the highest relative value for the business (business > PO > backlog > sprint backlog), and get immediate production feedback, as fast as you deliver, so that you know what to do. Some companies perform tens/hundreds of releases a day, others release once a day, others once a week, and so forth.


05:28 pm January 29, 2019

This section of the Scrum Guide talks about the Increment which is the goal of every sprint. 

https://www.scrumguides.org/scrum-guide.html#artifacts-increment

The guide also states that the Development Team should be delivering a "potentially releasable Increment of "Done" product at the end of each Sprint."  But no where does it say when it should be released.  In the section of the Scrum Guide where the Definition of Done is discussed there is this statement

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. 

There is no "rule" on when an increment is released.  It is up to the Product Owner to make that determination.  There are a lot of factors that can impact the decision such as can the users absorb a new release at this time, are market conditions acceptable of a release, can your company's support organization deal with a release at this time and many more. 

You asked:

Is there any industry standard or most recommended approach for any sort of relation of production release cadence with Sprint cycles or even at a regular cadence? (I understand hiccups happen, and sometimes hotfixes might need to be applied outside of a cadence).

To answer your question, it depends.  Not in the software industry, Scrum or agile community.  However you might find some "standards" in the industry for which you are releasing software.  For example, in the United States a lot of the retail support software companies will not release anything but hotfixes after the first of October through end of the year because of the potential impact to holiday shopping. Have your Product Owner look at your stakeholder's industry to find those kind of "standards".

However, I agree with the things that @Eugene said about missing the point of agile as stated in the Agile Manifesto for Software Development.  If you wait too long between releases are you really getting timely feedback with which to adapt rapidly to provide continuous benefits to the end user?


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.