The conversation goes like this. Friday standup. Engineering lead, calmly: "We shipped four stories this sprint. Velocity is up." Marketing director, also calmly, but with eyes that suggest otherwise: "We're three weeks from launch and the integration with the payment provider still isn't done."
Both statements are true. Both speakers think they're talking about the same project. They aren't.
Two cadences, one program
Every working product team operates on two clocks at once, whether anyone says so or not.
Sprint cadence is engineering's currency. Two-week loops. Story points, velocity, backlog grooming, sprint review. The unit of progress is "stories shipped". The audience is the team.
Delivery cadence is the business's currency. Milestones tied to outcomes. Launch dates, partnership commitments, marketing campaigns, contractual deliverables. The unit of progress is "milestones hit". The audience is everyone else.
These cadences are not the same. A team can hit sprint after sprint and still miss the milestone. A team can crush the milestone after a brutal sprint that looked like failure on velocity metrics. The two clocks tick at different rates and measure different things.
Where it goes wrong
The usual failure mode is one cadence absorbing the other.
When sprint cadence dominates, the team reports up in story-point language to people who don't speak it. Stakeholders nod, lose track, then panic three weeks before launch when they realize "story 47 done" wasn't progress toward anything they care about. The team did good work; the program failed.
When delivery cadence dominates, the milestone becomes the only fact that matters. The team is told to "just get it done by the launch date". Sprint discipline erodes — no real planning, no real retros, just heroics. The milestone hits; the codebase is a wreck; the next milestone slips because the wreck has to be fixed before anything new can ship.
Either failure is invisible to anyone watching only one clock.
What delivery managers actually do
The job, when this role is done well, is to translate. Sprint outcomes into milestone progress, and milestone risk into sprint priorities.
That means:
- After every sprint review, the delivery manager produces a one-paragraph translation: "We shipped X, Y, Z this sprint. In milestone terms, this means we're on track for the May 15 launch on the storefront, and we still have an open risk on the subscription cutover."
- Before every sprint planning, the delivery manager pre-prioritises based on milestone risk: "The biggest risk to May 15 is the Stripe webhook handler. We need that in this sprint, even if it bumps out feature Y."
These two artifacts — the post-sprint translation and the pre-sprint priority — are the entire job at one level. Without them, the cadences drift. With them, the cadences stay coupled.
Practical rituals
A few things to add if you're running both clocks:
Monthly milestone review. Separate from biweekly sprint review. Different audience, different format. Focuses on outcome progress, named risks, decisions needed from stakeholders. No story points.
The "what just happened" memo. Written by the delivery manager at the end of each sprint. Two short paragraphs, in plain prose, addressed to non-engineering stakeholders. What shipped. What that means for the launch. What's at risk.
Milestone risk register, separate from sprint risk register. Sprint risks are operational ("the test environment is down"). Milestone risks are strategic ("we won't have a working subscription cutover in time"). They get conflated when you only keep one register.
The takeaway
A team running pure Scrum without a delivery cadence is shipping software, not shipping outcomes. A program running only on milestones without a sprint discipline is heroics in slow motion.
You need both clocks. You need someone whose explicit job is to keep them coupled. When the conversation starts diverging — "we hit our sprint" vs "we're behind on launch" — that's the signal that nobody is doing the translation. Fix that, and most of the rest of the program management work gets easier.