Delivery cadence: the rhythm you work to, and how often something actually ships

Cadence is the rhythm the work runs to. Delivery cadence is how often finished output actually reaches the people who asked for it. Those are two different numbers, and a team can hold a steady two week rhythm while delivering once a year.

Cadence is the rhythm, delivery is the arrival

The Association for Project Management defines cadence as the number of days or weeks in a sprint or release, the length of the team development cycle. Notice what that definition contains and what it does not. It is a property of how the team works. It says nothing about when anybody outside the team receives anything.

That gap is where most of the confusion sits. A team running two week iterations has a two week cadence, and if the output of those iterations accumulates in a staging environment until an annual release window, the delivery cadence is twelve months. Both numbers are true. Reporting only the first produces the peculiar situation where a team describes itself as delivering fortnightly to stakeholders who have not received anything since last spring.

Single, multiple and periodic delivery

Delivery patterns come in three shapes, and the choice is usually made by the nature of the output rather than by preference.

Pattern	When output lands	What it costs
Single	Once, at the conclusion	All feedback and integration arrive at the end
Multiple	Several times, at irregular points	Each release needs its own decision and effort
Periodic	On a fixed repeating schedule	Discipline to ship on the date, ready or not

Single delivery develops the whole outcome across the life of the work and hands it over once, at the end. This is the right answer more often than the current fashion admits: a bridge, an office relocation and a regulatory submission all deliver once, because a third of a bridge is not a third of the value. The cost is real, though, and it is concentration. Every integration problem and every piece of feedback arrives in the last stretch, when there is least room to respond.

Multiple delivery hands over several times at points that make sense for the work rather than on a schedule. It suits output that splits naturally into pieces of unequal size.

Periodic delivery hands over on a fixed repeating interval, monthly or quarterly or every sprint. The predictability is the product: everyone downstream can plan against a date they already know.

These map onto the life cycle the work is running. The APM describes a linear life cycle as one sequenced into distinct phases, from the initial concept to the deployment of an ultimate outcome, which is single delivery by construction, while iterative life cycles repeat phases and create the opportunity for output to land more than once.

A rhythm you can hold beats a rhythm that looks fast

The instinct when setting a cadence is to pick the shortest interval the team can survive. It is the wrong optimisation, because almost all of the value in a cadence comes from it repeating rather than from it being short.

A fixed interval lets everything downstream stop negotiating. Testing knows when work arrives. Support knows when to prepare. A sponsor knows which meeting will have news in it. None of that requires the interval to be two weeks; it requires it to be the same interval it was last time. A predictable six week cycle is worth more to the organisation around it than a two week cycle that lands on the third Thursday, then the following Monday, then whenever the release freeze lifts.

There is a measurement cost to changing it, too, and it catches people out. Velocity is denominated in the cadence, while throughput and cycle time are not, so a team moving from three week to two week iterations sees its velocity drop by a third overnight while doing exactly the same amount of work. Every historical comparison across that boundary is meaningless, and someone will quote one anyway.

Choosing the interval

Two questions decide it, and neither is about the team.

Can the output be split into pieces that are usable alone? Not merely shippable, usable. A third of a payroll migration is not a third of a payroll, and delivering it produces a support burden rather than value. Where the answer is no, single delivery is not a failure of ambition, it is a correct reading of the work.

Can the receiving side absorb it? This is the one that gets skipped. Delivery is not complete when something is released; it is complete when somebody uses it. An organisation that retrains its staff twice a year cannot absorb a monthly release however smoothly the team produces one, and pushing anyway generates a queue of undeployed increments that looks like delivery on your reports and like nothing at all to the people it was for.

Where both answers are yes, the useful rule is to choose the longest interval that still returns feedback in time to act on it. Shorter than that spends coordination effort on information you will not use; longer than that means the first real signal about a decision arrives after the decision has become expensive to reverse.

The cadences you are already running

Almost nobody runs one. A typical piece of work carries a daily rhythm for the team, a two or three week rhythm for planning and review, a monthly rhythm for reporting, and a quarterly one for funding or governance. Each was set by a different person for a different reason, usually years apart, and they are rarely examined together.

They should be, because the trouble is not the number of rhythms but how they line up. When the intervals are whole multiples of each other, the cycles nest: three two week iterations fit exactly inside a six week reporting period, so every report lands on the same point in the cycle and describes the same kind of moment. When they are not multiples, the cycles drift against each other. A monthly steering meeting against a three week iteration means the meeting arrives mid iteration, then just after one closes, then mid iteration again, and the quality of what is available to report swings for reasons that have nothing to do with the work.

The drift is easy to miss because each individual meeting has a plausible explanation for being thin. Over a quarter it produces a distinct pattern: reports that alternate between substantial and defensive, and a governance forum that slowly forms the view that delivery is erratic.

The fix is not usually to change the team’s rhythm, which is the one with the most reason to be what it is. It is to move the reporting or governance interval onto a multiple of it, or to accept the drift explicitly and report against iteration boundaries rather than calendar months. Either works. Doing neither means the calendar quietly sets the agenda.

What a cadence cannot fix

A cadence is a container. It sets when things happen and never what goes in them, and every failure attributed to the wrong cadence on inspection turns out to be something else.

Work that is not finished at the end of an interval is not a cadence problem, it is a sizing problem, and shortening the interval makes it worse. A backlog of undelivered increments is not a cadence problem, it is an absorption problem. A team that cannot say what it will produce next cycle does not need a different rhythm, it needs a clearer intake.

The one thing a cadence genuinely provides is a repeating moment at which the same questions get asked: what did we finish, what did we learn, what is next. That is not a small thing, and it is the whole of what the rhythm buys. Everything else attributed to cadence, the speed, the quality, the predictability of the content rather than of the date, comes from the work itself. The rhythm just makes sure somebody looks up regularly enough to notice.