A sprint is a box. Two weeks, usually: a fixed window of time that the team fills with work, empties and fills again. When I started running delivery teams, that box was a gift. Shipping was an event back then — releases took a quarter, sometimes two — and committing to working software every couple of weeks felt almost reckless.
Then teams got fast. DORA’s elite performers deploy on demand, multiple times per day, and even solidly high-performing teams ship somewhere between daily and weekly. I’ve watched teams push to production three times before lunch. Which raises an awkward question: if your team ships on Tuesday afternoon because the work was ready on Tuesday afternoon, what is the two-week box doing for you?1
Mostly, it’s overhead.
If you’re new, welcome to Customer Obsessed Engineering! I publish about one article each week. Free subscribers can read about half of every article, plus all of my free articles.
That’s the short version of why “sprint” no longer appears in the Delivery Playbook’s prescriptive text. The longer version is worth telling, because it applies to more than one word — and if you maintain a playbook, a wiki or a set of team standards of your own, the same quiet misalignment may be growing in yours.
What is the box actually buying you?
I know the counter already. “A sprint isn’t a release cycle, it’s a planning rhythm. We deploy continuously; we plan in two-week windows.” Fair. Plenty of capable teams run exactly that way.
But look at what the rhythm does. A two-week planning boundary is a batch. The word comes from baking: a batch is the quantity of bread baked at one time. You collect, then you bake. Sprint planning collects two weeks of decisions and bakes them together; the demo and the retro collect two weeks of feedback and serve it cold. Batching decisions made sense when deciding continuously was expensive. It isn’t expensive anymore. When your pipeline moves a story from start to production-ready in days, holding decisions for a ceremony every other Thursday is a delay you chose. The feedback already arrived. The next most valuable thing may have changed. The box didn’t change.
Count what the box costs at that speed. Planning sessions whose real job is filling it. Estimation whose real job is capacity math. Carryover accounting when the guess ran long. Velocity — a number too often tied to the box, not value delivered. None of that moves work to production. It exists to serve the container.
I made this argument about PI planning in Can you rely on SAFe to deliver elite-performer gains? — a quarterly batch is too slow for teams that learn weekly. The two-week sprint earns the same critique at a faster scale. It’s a smaller batch, but it’s still a batch, and the ceremonies still pile up at its edges.
None of this makes Scrum incompatible with high performance. Teams win with it every day, and if the timebox is genuinely serving yours, keep it. But when a team asks me what I recommend, I point at kanban: limit work in progress, pull the next most valuable item when capacity opens and let your rhythm come from the work instead of the calendar. The rituals survive, by the way. Daily syncs, retros, reviews — they simply run on the team’s cadence rather than the box’s.
What the word was doing in the playbook
Here’s the thing about the Delivery Playbook: it never tells you to run Scrum. Read all twenty-eight chapters and you won’t find the word once. What the playbook prescribes is narrower and travels better: keep each unit of work small enough to reach production-ready in days, and let the team own its rhythm.
But “sprint” showed up anyway. Sprint backlogs, sprint planning, stories that “fit comfortably inside a sprint.” Each mention was casual. Together, they were quietly aligning the playbook with “you should be sprinting” — a recommendation I never intended and don’t hold. Repeat a word often enough and it stops reading as an example. It starts reading as the model.
Who the word was failing
A playbook is for the team actually holding it, and this word was failing three different teams in three different ways.
The kanban team reads “sprint backlog” and concludes the playbook isn’t written for them. That’s the worst outcome of the three, because they’re the audience the playbook fits most naturally. It has been flow-shaped from the start.
The Scrum team stays, but learns the wrong lesson. “Fits inside a sprint” teaches that stories are small so the capacity math works out. The playbook’s actual claim is that stories are small so value and risk surface in days; the timebox has nothing to do with it. Right practice, wrong reason.
The waterfall team, running a gated process today and honestly trying to improve, reads sprint vocabulary as a sign the whole thing assumes a maturity they don’t have yet. And closes the tab. Also wrong. If you run a gated process, your first increment may be an entire release; the activities still work, and each pass exposes the seams for shrinking the next one.
Nobody should bounce off a vocabulary choice. Now nobody has to.
What changed — and what didn’t
The prescriptive vocabulary now runs on three words, consistent across every chapter, table, template and the glossary:
Increment — the unit of delivery: the smallest amount of work that puts a high-value feature into your customer’s hands. Cadence-agnostic by construction.
Cadence — the rhythm, whichever one the team chooses.
Cycle — the informal countable, for when “in one short cycle” reads better than anything stiffer.
And here’s what didn’t change: “sprint” isn’t banished. Inside 3.3’s fitting-your-cadence lanes, the Scrum lane speaks fluent sprint, because there it’s the precise word. The war stories keep their sprints too. When I tell you we delivered something in two sprints, that’s what we ran, and history doesn’t get a rewrite.
The same consistency sweep caught a second word, in a minor key: “product owner” now appears only where the meaning is genuinely Scrum-specific. Everywhere the playbook names its own model, the role is the product manager, one third of the product trio alongside the product designer and tech lead. If the trio is new to you, 1.1 Team mobilization defines it and Building a product oriented team makes the argument.2
GembaKai got the same pass
The playbook’s online reference at gembakai.us received the identical sweep in the same week. Chapters, guides, templates and tables all speak the same three words now, on both surfaces.
And the reference grew while we were in there. Two pieces moved into the playbook proper: How product teams outperform, which assembles the research case — DORA, McKinsey’s five-year study of 1,700+ teams, the feature-usage data — and Building your team, which lays out the team model itself. Both sit in the introduction, open to everyone. The playbook now makes its own argument from the first page.
If you’re reading the playbook now
You’ll notice the change mostly by what you stop noticing. The model didn’t move. Trunk-based development, flow metrics, the steel thread and small production-ready units of work have been the playbook’s spine since the first chapter. The words just got a consistency pass.
Check the glossary if you want the clear definition on each term, or 3.3 Identify product increment if you want to see the cadence lanes at work. And if your own team standards have been quietly borrowing a timebox you never chose — well, now you know what to look for.
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
DORA, Accelerate State of DevOps research, Google Cloud — dora.dev. Elite performers deploy on demand (multiple deploys per day); high performers ship between once per day and once per week.
Marty Cagan, Inspired (Wiley, 2018). Cagan draws the same line: “product owner” names a backlog-administration role, while the product manager owns value and viability.