Sprint boundaries in a world of hourly cycles

There is a specific moment in a sprint that always felt slightly absurd, and it feels considerably more absurd now.

It is Thursday of week two. A piece of work is finished. Merged, deployed, verified, done. And it sits, not because anything is wrong with it, but because the sprint ends Friday and the review is Friday afternoon and the story will be counted then. Meanwhile a different piece of work is nearly done, and there is a quiet conversation about whether to rush it so it lands inside the boundary, which means it will be finished slightly worse than it would have been on Monday, in order to be counted on the correct side of a line that exists because someone in 1995 decided that a month was too long and a week was too short.

Nobody thinks the line is real. Everyone behaves as though it is, because behaving otherwise makes the numbers look wrong.

Thursday of week two. The work is merged, deployed, verified, done. It sits, because the sprint ends Friday and moving it now distorts the burndown, and next sprint starts light.

Everyone behaves as though the line is real, because behaving otherwise makes the numbers look wrong. Compress the underlying cycle to four hours and the ratio of real work to arbitrary boundary gets worse, not better.

Now compress the underlying cycle. Work that took three days takes four hours. A change can go from specification to production in an afternoon. The sprint boundary has not moved, so the ratio has changed: instead of a container holding maybe fifteen units of work, it holds eighty. The boundary is doing less and less useful containing, and the distortion at the edges is proportionally larger.

So does the sprint go away? I think the answer is genuinely more interesting than yes or no, and it depends on separating four different things a sprint does that got welded together for historical reasons.

The four jobs of a sprint

Batching for planning efficiency. Planning had a fixed cost: get everyone in a room, argue, produce a commitment. If that costs four hours, you do not do it daily. You amortise it over two weeks. The sprint length is essentially the solution to an optimisation problem where the numerator is planning overhead.

Batching for release safety. Deployment used to be dangerous. Batching changes and testing them together as a release candidate was risk management, and the sprint boundary aligned with the release boundary in a lot of organisations. This job was mostly dismantled by continuous delivery a decade ago, and its remnants persist in places mostly by habit.

A commitment window for stakeholders. A promise with an expiry date. “By the end of the sprint you will have X.” This gives the business a predictable interval at which reality is compared to expectation, and it gives the team a shield against mid-sprint scope injection.

A rhythm for reflection. Retro. A recurring, protected moment where the team examines its own process rather than its output. This is the job that has nothing to do with batching at all and got attached to sprints purely for convenience.

Agents demolish the first, finished off the second, complicate the third, and leave the fourth entirely untouched. That asymmetry is the whole argument.

Batching for planning efficiency

Amortising a four-hour planning cost over two weeks. Dead: derived plans collapse the cost.

Batching for release safety

Dying for ten years on its own. Large batches are what make deployment dangerous in the first place.

A commitment window

Complicated rather than dead. Stakeholders need something, and "look at the dashboard" is not an interface.

A rhythm for reflection

Entirely untouched. Retro has nothing to do with batching and every reason to survive.

The batching case is gone

Job one dies because the planning cost collapsed. If plans are derived (read continuously from source control rather than asserted in a session, as argued in the first piece of this series) then there is no four-hour ceremony to amortise. Prioritisation still requires human decisions, but prioritisation is a much smaller act than planning, and it can happen continuously as a queue rather than periodically as an event.

Job two is a straightforward argument that has been made better by other people for ten years. Batching changes to reduce deployment risk is exactly backwards: large batches are what make deployments dangerous. Small, frequent, independently deployable changes are safer, and the industry’s own metrics research has consistently found that deployment frequency and stability move together rather than trading off. Agents raise the possible frequency and therefore make batching more costly, not less. Every hour a merged change sits undeployed is an hour of accumulated divergence and a larger blast radius when it finally goes.

So two of the four jobs are dead or dying, and both of them are the ones that determined the length of the sprint. Which is the point: the two-week number was derived from the batching costs. Remove the batching costs and the number has no basis. Teams that keep two weeks after removing the batching rationale are keeping an arbitrary number for reasons they cannot articulate, which is fine as long as they know that is what they are doing.

The commitment window gets complicated

Job three is where it gets genuinely difficult, and I do not think there is a clean answer.

Stakeholders need something. “We work continuously and you can look at the dashboard” is not an acceptable interface to a business that has to make commitments to customers, plan a marketing launch, or brief a board. The sprint commitment, for all its fictions, gave the organisation a rhythm of promises it could plan around.

At the same time, sprint commitments in an agentic team are unusually unreliable, for a slightly counterintuitive reason. It is not that the work is less predictable. It is that the variance profile changed shape. When a human implements a ticket, the duration distribution is wide but familiar: mostly two to four days, occasionally a week, rarely three weeks. When an agent implements a well-specified ticket, the distribution becomes bimodal. Either it works in about an hour, or it fails in a way that reveals the specification was ambiguous and the whole thing becomes an open-ended human problem. There is much less middle.

Bimodal distributions are terrible for commitment windows. The average is meaningless (nothing takes the average time) and any fixed-size commitment is either mostly padding or frequently missed. This is why teams often report that agentic delivery feels less predictable even though their aggregate throughput went up considerably. Both things are true.

The direction that seems to work: commit to outcomes at coarse intervals and let the flow be continuous underneath. A monthly or six-weekly commitment about what capability will exist, with continuous delivery of the pieces, rather than a fortnightly commitment about which tickets will close. The coarser window absorbs the bimodal variance. The continuous flow means nothing waits at a boundary. And crucially the coarse commitment is about user-visible capability rather than internal work items, which is what the stakeholder actually cared about anyway.

Six weeks is not a magic number, but it recurs often enough in practice to be worth noticing. It is long enough that the tail of one badly-specified item does not blow the commitment, and short enough that being wrong is recoverable.

The rhythm is worth keeping, and it is not about the work

Job four is the one I would defend hardest, and it is worth being explicit that it has nothing to do with any of the arguments above.

Humans need periodicity. Not for planning reasons, for cognitive and social ones. A pure continuous flow with no boundaries produces a specific and well-documented set of problems: no natural point to reflect, no sense of completion, no shared moment of “we finished something,” and a slow erosion of the ability to distinguish a good month from a bad one. Continuous flow feels like a treadmill precisely because a treadmill has no boundaries either.

The interesting bit is that agents make this worse. When the cycle underneath is hourly, and work is flowing constantly, and there is always something in flight, the psychological need for punctuation goes up rather than down. Teams running continuous agentic delivery with no rhythm report the burnout profile of an always-on operations team, which is what they have accidentally become.

So keep the boundary. Just be clear that you are keeping it for the retro and the sense of completion, not for the batching. And having admitted that, the boundary can be whatever length actually serves reflection: weekly is often better than fortnightly for this purpose, because the material is fresher and the session is shorter.

The specific practice I would keep unchanged from Scrum, with no modification at all, is the retrospective. It was always the most valuable ceremony and the first one teams cut when they get busy. In a world where the process is changing under your feet every month, a protected recurring session for examining the process is more valuable than it has ever been.

What the boundary is for now

Putting it together, a boundary in an agentic team is doing roughly this:

• Reflection. What went well, what did not, what class of thing keeps costing us. Weekly or fortnightly.
• Recalibration of the derived plan. Not “what will we commit to” but “given what we now observe about cycle times and where work is thrashing, is our priority order still right.”
• Demonstration. Showing what exists, to people who do not read pull requests. This retains its full value and possibly gains some, because when delivery is continuous, nobody outside the team has any idea what changed.
• Completion. A moment where the team collectively marks that a chunk of work happened. Underrated, unmeasurable, load-bearing.

And it is explicitly not doing: batching deployment, gating work from being finished, or serving as a container that things must fit inside.

That is a much lighter boundary than a sprint. It has no commitment ceremony, no estimation session, no burndown, and no notion of work being “in” or “out” of it. It is a beat rather than a box.

Where this breaks down

Where I would push back on my own argument.

Coarse commitments are a harder sell than they sound. “We commit to a capability in six weeks rather than a set of tickets in two” is a more honest interface and a less legible one. A stakeholder who has spent a decade tracking sprint commitments has built their own reporting on top of it, and asking them to change is asking them to renegotiate their own accountability upward. Many will refuse, and the team will end up maintaining a sprint ceremony purely as an external interface while working continuously underneath. That is a defensible compromise but it is worth naming as the overhead it is.

Continuous flow without boundaries genuinely does hurt people. I have argued for keeping the rhythm, but I want to be stronger about it. The teams that get this wrong do not get it slightly wrong. Removing all periodicity from knowledge work is a known route to a bad place, and it fails slowly enough that nobody attributes it to the process change. If you are going to remove sprints, install the replacement rhythm first and in the same change, not as a follow-up you will get to.

Bimodal variance might be a transitional artefact. My claim about the distribution shape is an observation about the current state of tooling and practice, and the current state is moving fast. If specification quality improves and agent reliability improves, the failure mode gets rarer and the distribution tightens, at which point fixed-size commitments work better than I have suggested. I would not build a five-year process strategy on the variance profile of 2026.

Some organisations are structurally periodic and that is not negotiable. If your company plans quarterly, budgets quarterly, and reports to a board quarterly, then delivery rhythm has to interface with that at some point. Continuous flow inside a periodic organisation creates a translation layer, and somebody has to staff it. Pretending the organisational periodicity will yield to a better engineering practice is a way to lose an argument you did not need to have.

And a small one that matters: the two-week sprint is a coordination standard across teams. If four teams share dependencies and three of them run fortnightly, the fourth going continuous creates a synchronisation problem that did not previously exist. The cost of being different is real and is usually borne by the team that changed. Going first is a political act as much as a process one.

The takeaway

The sprint welded together four separate jobs. Two of them (batching for planning cost, batching for release safety) determined its length and are now gone. One of them (the stakeholder commitment) survives but wants a coarser, outcome-shaped window that can absorb bimodal variance. And one of them (rhythm and reflection) never had anything to do with batching in the first place and is more valuable than ever.

So the answer is not “sprints are dead.” It is that the box became a beat. Keep the boundary, drop the container.

Once work flows continuously and nothing waits at a boundary, the individual change becomes the only real unit in the system: the thing that is proposed, checked, approved, merged and deployed on its own. That makes the pull request carry weight it was never designed to carry. The next piece is about what happens when it becomes the primary place governance lives.