Production release cadence as relates to Sprint cycle
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).
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.
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.
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?