Sprint length for teams running coding agents
Stefan-Iulian Tesoi · · 6 min read
Sprint length should be the larger of two numbers: how long your items actually take to finish, and how often something arrives that would change what you picked. Agents collapse the first and leave the second untouched, which is why one week fits most teams and why the answer is not simply "as short as possible".
Most teams shorten the sprint and never notice they were only ever measuring the first number.
What should sprint length be set by?
Two numbers, and the boundary belongs at whichever is larger.
The first is how long work takes to get through. The Kanban Guide's formal version is a service level expectation: a forecast with an elapsed time and a probability, of the form "85% of work items will be finished in eight days or less". A sprint shorter than that guarantees items straddling the boundary — less a scheduling inconvenience than a reporting fiction, since the sprint reports what finished inside an interval it was never sized to contain.
The second is how often you learn something that would change the plan: a customer escalates, a dependency slips, an experiment returns a number. If that happens weekly, a fortnight of committed scope means half the sprint answers a question nobody is asking by the time it is answered.
A sprint boundary is a re-decision point. Making it more frequent than your cycle time buys nothing but straddled items; making it less frequent than your rate of learning buys staleness.
For twenty years the first number was the larger one, so how long should a sprint be was effectively a question about engineering. It is not any more.
Why did two weeks stop fitting?
Because two weeks was the cycle-time number, and agents collapsed it while nobody re-derived the boundary.
A fortnight was never arbitrary: it was roughly how long a small team took to carry several stories to something worth demonstrating, with slack for a bad week. The boundary fell naturally where a batch of work became showable.
When a coding agent executes a specified item in under an hour, that justification is gone. What is left is the second number — how often the plan should be reconsidered — and that is a property of the business rather than the engineering team. It did not change when the agents arrived.
The awkward consequence is that sprint cadence is now mostly a commercial question wearing an engineering label. A team whose priorities shift weekly and one whose roadmap holds for a quarter should not run the same length — and before agents they largely had to, because cycle time dominated both.
| How often the plan would change | How long items take to finish | Sensible boundary |
|---|---|---|
| Weekly or faster | Hours to a day | One week, or drop the boundary for continuous flow |
| Every few weeks | Hours to a day | One week — frequent enough to re-decide, long enough to leave alone |
| Monthly or slower | Hours to a day | Two weeks, and expect planning to be brief and dull |
| Any rate | Several days | Match the cycle time first; the items are too big to choose freely |
The last row is the common case and the least discussed. A team whose items still take days has not been limited by sprint length at all.
What actually breaks in a one-week sprint?
Three things, and only one of them is the ceremony cost everyone expects.
The first is straddling. One week sprints leave five working days, so an item that takes three has a real chance of crossing the boundary whatever day it starts. That shows up as carry-forward rather than failure — in Laimonade unfinished items carry into the new sprint keeping their column, and the sprint workflow records completion dates so history survives the status being overwritten. Carry-forward is correct behaviour and a bad habit to rely on: a sprint where a third of the items arrived from last week is not measuring a week.
The second is holidays, which nobody mentions and everybody feels. One public holiday removes twenty per cent of a one-week sprint and ten per cent of a fortnight, and four-day weeks are common enough that a weekly cadence should expect several a year where the plan was wrong by a day.
The third is the planning tax, and it is the smallest. A readiness check over the top of the backlog takes about twenty minutes, not the two hours estimating against capacity used to. Doubling the frequency of a twenty-minute meeting is not what makes a week expensive.
- Size items to finish inside a day, which removes the first problem rather than tolerating it.
- Do not re-plan a four-day week as if it were five. Carrying the shortfall forward is honest; pretending is not.
- Keep the boundary on a fixed day. Laimonade closes sprints on Monday in the project's timezone, and the day matters far less than it never moving.
Should the cadence be continuous instead?
If you can answer one question, yes. The question is what you would drop if something urgent arrived this morning.
A team that can name it immediately is already running flow, and the boundary is a ceremony on top. A team whose honest answer is "we would wait until Monday" is using the boundary for something real: it stops the plan being renegotiated daily, and removing it costs more than the meeting it saves.
Continuous flow replaces the boundary with a work-in-progress limit: the constraint moves from when you re-decide to how much is in flight. That works when the specification supply is steady and review happens the same day, and badly when either is lumpy, because nothing forces the backlog to be read as a whole.
The honest position for most teams running agents is a weekly boundary they could probably drop, kept because the weekly look at the whole board catches what a per-item flow does not. Why that boundary now batches review rather than building is in what changes about sprint planning with AI agents; what the cadence means for the person holding a team is in for engineering leaders, and the mechanics in how Laimonade works.
Frequently asked questions
Does a shorter sprint mean more meetings?
More often, and less total time. Planning against readiness takes about twenty minutes rather than the hour or two estimating against capacity took, so a weekly cadence costs less per month than a fortnightly one did. What does double is the review at the boundary, which is real work rather than ceremony.
How do you handle work that takes longer than a sprint?
Split it so it does not, and treat the exceptions as exceptions. An item that genuinely cannot finish inside a week usually contains several outcomes rather than one, and splitting reveals work nobody had priced. For the real cases — a migration running against production data over several days — let it carry forward and stop counting it twice.
Can different teams run different lengths?
Yes, and it is usually better than forcing one. Cadence should follow how often each team's priorities actually change, which differs between a team on a compliance roadmap and one shipping against customer escalations. What should be shared is the definition of done and the review bar, because those make work comparable across teams. The calendar does not.