Ask two experienced release managers how often you should ship and you will get two confident, opposite answers. One will tell you to fix the cadence and let scope flex. The other will tell you that shipping on a calendar rather than on readiness is how you end up releasing something nobody wanted on a Tuesday.
Both are right, and the argument usually goes nowhere because it is framed as a scheduling preference. It is not. Your release cadence decides which variable absorbs the bad news when the work takes longer than you thought — and that is a much more interesting question than how often to ship.
What a fixed release cadence actually buys
A fixed cadence — every four weeks, every quarter, the second Thursday — makes the date a constant. Everything else in the organisation gets to plan against it: support staffing, documentation, marketing, customer comms, the regulated sign-off that takes eleven days no matter how you feel about it.
That is a real and underrated benefit. Most of the pain in release coordination is not engineering pain; it is the cost of every downstream team having to re-plan every time a date moves. Fix the date and that cost disappears.
But the constraint has to go somewhere, and under a fixed cadence it goes into scope. If the work is not done, the train leaves without it. That is the whole logic of the agile release train: a fixed departure, a variable manifest.
What ship-when-ready actually buys
On-demand releasing holds scope constant and lets the date move. Nothing ships half-finished to hit an arbitrary Thursday, and nothing finished sits in a queue for three weeks waiting for the next window.
For a team with genuinely independent deployability and low coordination overhead, this is usually the better trade. The catch is that the coordination cost did not vanish — it moved onto everyone downstream, who now have to be permanently ready rather than ready on a schedule. Teams adopt on-demand releasing for engineering reasons and abandon it for organisational ones.
The question underneath the question
Here is the reframe worth taking into the argument. Both models are honest right up until the work runs long. Then:
- Under a fixed cadence, a miss is a scope decision. Someone has to say which items come off the train, and say it early enough that it is a choice rather than an observation.
- Under ship-when-ready, a miss is a date decision. Someone has to tell the people waiting that it is now later, and say when — which means producing a new date they can rely on.
Notice that both decisions need the same input: a current, honest projection of when the remaining work will actually be finished. Neither cadence gives you that. Cadence sets the shape of the conversation; it does not supply the number the conversation needs.
This is why teams switching cadence so often report that nothing improved. They changed which variable flexes without changing how early they can see the flex coming. A fixed cadence with no forward view produces a manifest that gets rewritten in the last three days. Ship-when-ready with no forward view produces a date that slips one week at a time, announced one week at a time.
Choosing, in practice
Three questions settle it faster than a principles debate:
- How expensive is a release event for the people who are not you? If regulated sign-off, customer notification or field training make each release costly, a fixed cadence amortises that cost. If a release is a deployment and a changelog, it does not.
- How coupled is the work? Multiple teams that must ship together are already on a shared cadence whether they admit it or not. Independent services are not.
- Which conversation is your organisation better at having? Some can cut scope calmly. Others cannot, and for them a fixed cadence just produces quiet quality compromises to make the date. Pick the failure mode you can actually manage.
Whichever you choose, keep the forecast running underneath it. Release Management, Roadmaps, Portfolio PPM & Timeline for Jira projects a release date from the team’s own delivery history rather than from the plan, and reports it as a confidence band rather than a single hopeful day. Under a fixed cadence that band tells you which items will not make the departure while there is still time to choose. Under ship-when-ready it gives you a defensible next date instead of a weekly apology. The mechanics are covered in release date forecasting.
For the wider picture, our complete guide to release planning in Jira covers how cadence fits with scope, capacity and commitment. Two adjacent decisions are worth reading alongside this one: how many sprints belong in a release sizes the interval once you have chosen one, and roadmap versus release plan separates what you intend to build from what you have committed to ship.
Key takeaways
- Release cadence decides which variable absorbs a miss: a fixed cadence flexes scope, ship-when-ready flexes the date.
- A fixed cadence is worth most when a release event is expensive for people outside engineering, or when several teams must ship together.
- Ship-when-ready does not remove coordination cost — it transfers it to everyone downstream, who must now be permanently ready.
- Both models need the same input when work runs long: a current projection of when the remaining work finishes.
- Changing cadence without improving forward visibility changes the shape of the failure, not the frequency of it.
- Pick the failure mode your organisation can actually manage — cutting scope calmly, or communicating a new date credibly.
Frequently asked questions
What is a good release cadence for an agile team?
There is no universal number, but there is a useful test: your cadence should be short enough that a missed item waits days rather than months for the next window, and long enough that the fixed cost of a release event is worth paying. For most product teams that lands somewhere between every sprint and every quarter. Teams whose release event is genuinely cheap should question whether they need a cadence at all.
Is release cadence the same as sprint length?
No, though they are often confused because many teams release at a sprint boundary. Sprint length sets how often you re-plan; release cadence sets how often you ship to users. They can be the same interval, but coupling them is a choice rather than a requirement — plenty of teams plan fortnightly and release quarterly, and some plan fortnightly and release continuously.
Leave a Reply
Your email is safe with us.