Sprint Cadence
Concept
The length chosen for one sprint, set once and then kept identical rather than adjusted per cycle.
Why it exists
Plenty of teams used to set the length per cycle. Three weeks this time because there's a lot to do, one week next because something is urgent, two and a half after that because vacations land in the middle. Matching the situation every time looks reasonable.
Two things break when you do. The first is comparison. Laying last cycle's output beside this cycle's requires the lengths to match, and comparing three weeks against one tells you nothing. Velocity, the average a team completes per cycle, stops existing as a concept. Everything built on that average goes with it — the planning total, the quarterly forecast.
The second is the calendar. A length that changes moves the planning meeting and the retrospective with it, and nobody can commit those dates to memory. Fixing the cadence buys both of those, and the price is giving up the flexibility to match the situation. A fixed rhythm is information the team no longer has to hold.
How it works
Pick one length between one and four weeks and keep running it. Four things to decide.
- Choose the length. Two weeks is the most common. Shorter brings feedback faster while raising the share of time the fixed meetings take; longer does the reverse. If planning, review, and retrospective cost four hours, that's 5 percent of a two-week cycle and 10 percent of a one-week cycle. A one-week cycle also shrinks how large a piece of work can fit inside it.
- Fix the start and end days. Starting Tuesday and ending the following Monday, for instance. Many teams avoid ending Friday, since a Friday deploy can leave a problem sitting through the weekend. Whatever the choice, writing it down once and never debating it again is the point.
- Don't extend the length when work isn't finished. A limit set as time you don't exceed is a timebox, and the cycle itself is one. Add two days once to get something finished and from then on the remaining work sets the length.
- Change it only at a boundary. Run at least three cycles before judging, and after a change throw out the old average and start collecting again. Moving from two weeks to three doesn't raise capacity by 1.5 times; it usually rises by less.
How it sounds at work
"Could we do three weeks just this once? Then the average is unusable."
Changing the length removes the basis for comparison.
"We run two weeks and the meetings take six hours. Let's trim."
The share going to fixed meetings is too high.
"We moved the end from Friday to Tuesday."
Avoiding the overlap between the weekend and a deploy.
Pagedeck runs two weeks, Tuesday to Tuesday. It used to end Friday, and Mia moved the day after two Friday-afternoon deploys spilled into the weekend. The length hasn't changed in two years. Nobody proposes changing it anymore, which is roughly the goal.
Where to go next
Last updated 2026-09-16