WIP, batch size, and the collapse of sprints

A feature that used to take a full sprint to build will now often be built and shipped within a single afternoon, and yet nothing about the calendar we had wrapped around that work has changed. We still hold the same two-week planning meeting, still open the board on Monday and close it on Friday, as if the pace of the work were what it had always been. By the second week of one of those cycles, sitting in a room while engineers walked everyone through features that had already shipped days earlier, I began to feel that the meeting was keeping time to a rhythm the work itself had quietly outgrown.

The common reaction is to declare that the sprint is dead, but I think that misreads what happened. When the work compresses to a matter of hours the sprint does not become shorter; it comes apart, into the several jobs it had always been doing at once, only one of which ever depended on the work being slow. That job dissolved when delivery sped up, and the others were left without the thing that used to hold them together, even though the need for them had not gone anywhere.

The three jobs hidden inside the sprint

For as long as most of us have worked this way, the sprint has carried three separate jobs at once, bundled together so tightly that we stopped noticing the seams between them. The first was a way of shipping work in bulk: every release carried some overhead, so it made sense to gather a batch of changes and send them out together, and a two-week cycle was a convenient way to spread that overhead across a meaningful amount of work. The second was a promise about scope, a commitment to what would exist by a particular date, so that a product manager or a partner team could make their own plans around what you had said would be ready. The third was a regular moment to re-align, a fixed point at which everyone stopped, took stock of where things stood, and got back onto the same page.

Only the first of these ever needed the work to be slow. Once a feature can ship the same day it is conceived there is nothing left to gather into a batch, and that job disappears. The other two never depended on slowness at all; they depended on people needing to coordinate with one another, and that need is as real as it has ever been. This is why the instinct to "kill the sprint" does more harm than good: it takes aim at the one job that has died and, in the same motion, discards the two that are still doing real work. Cut the re-alignment away along with everything else and the team does not become freer. It loses the one fixed point it had for getting back in sync, and within a month it grows a worse replacement, whether that is a standing meeting nobody quite decided to create or a manager who ends up doing all of the re-aligning in person, one conversation at a time.

On one team I worked with, almost everything shipped the same day it was picked up, and yet we were still holding a two-week planning ceremony largely out of habit. I asked, once, in the room, which of the three jobs the meeting was still doing. The bulk-shipping job was plainly gone, and the promise about scope had by then turned into a fiction nobody could honestly stand behind, so what remained was the re-alignment, and yet nobody wanted to say that out loud, because it was still wrapped inside a ritual that had originally been built to carry all three.

When the team turns rigid, read it as a warning

The clearest sign that the schedule has drifted away from the work will not show up in a metric; it shows up first as a change in mood, in the way a team begins to treat any change to the plan as a threat. On my own teams the pattern was always the same. We would grow strangely protective of the scope we had agreed to at the start of a cycle, until a perfectly reasonable mid-week request began to feel like a violation of process rather than an ordinary part of building something. The cycle still demanded a fixed picture of what the next two weeks would contain, the speed we were now delivering at had made that certainty impossible to offer honestly, and so we manufactured it instead, freezing the scope and telling ourselves that the freezing was discipline.

This has a healthy twin, and from a distance the two look almost identical. A team that protects a block of focused time from constant interruption is doing something sensible, and what I am describing is not that. When we froze the scope we were not protecting the work at all; we were protecting the ceremony, supplying the certainty the schedule demanded even though the work itself no longer had any need of it. From the outside, though, this looks a great deal like maturity, like a team that has finally learned to commit and to honour its commitments, so the natural response is to praise it and ask for more of it, and everyone in the arrangement comes out ahead: leadership sees commitment, the team gets credit for discipline, the ceremony gets its certainty. The bill goes to the one thing nobody was tracking, which is how well the team can absorb a change, and that was the thing already failing. The brittleness is a symptom of a schedule demanding a certainty the work can no longer truthfully provide.

Let planning and delivery keep different time

Once you can see that the sprint tied one fast job together with two much slower ones, the correction is reasonably clear: stop trying to run all three on a single schedule. The delivery side can run continuously, with a well-ordered backlog, sensible limits on how much sits in progress at any one time, and work going out the moment it is ready rather than when a two-week window happens to close. The slower jobs keep a separate and deliberately unhurried rhythm of their own, paced for the work that really does need people together in a room: deciding what to take on next, getting everyone aligned, and reflecting on how the work has been going. There is no law of nature that says the rhythm at which a team decides what matters must match the rhythm at which it releases code; the sprint only ever made it look that way because, for the better part of two decades, the two happened to run at the same speed.

In practice this becomes two artifacts where there used to be one. The stakeholder who once asked "what is in this sprint" now gets two answers instead: a live board they can look at whenever they like, which shows what is shipping, and a short written note once a week that says where the team is currently pointed. What is being delivered and where the whole effort is heading no longer have to share a single meeting between them.

Keep an eye on the slower rhythm trying, over time, to turn itself back into a gate. The pull is real, because a batched release gave everyone one tidy answer to what shipped this cycle, and the live board took that tidiness away. If the weekly planning conversation begins holding finished work back so that it can all be released together, the sprint has simply grown back under a different name. The slower clock is for deciding what matters, and the question of when a given piece of work ships belongs to the faster one. As long as the planning rhythm stays advisory the whole arrangement stays loose; the moment it is allowed to reach in and touch the release itself, it fuses back together the two cadences you had just gone to the trouble of pulling apart.

Size the work to what a person can take in

This is where the older theory needs a revision. The most powerful idea we inherited about flow, set out in Donald Reinertsen's work on product development, is that reducing batch size is the single most effective economic lever available to you, because large batches quietly inflate the queues you cannot see and slow down the feedback you depend on. Keep the amount of work in progress low, make each batch small, and the time it takes a piece of work to move through the system drops sharply. All of that remains true. What has changed is that the idea rested on two assumptions, and both of them have since come undone.

The first assumption was that a single unit of work corresponds to a single person holding it in their head, and the second was that the slow and expensive part of the whole business was the building itself. Neither is reliably true any more. Generating the code is now close to free, so a single engineer can have far more work in flight at once than any one person could keep track of, while the slow part of the work has shifted from the building to the reviewing, the judging, the integrating, and the deciding of whether the thing that was built was even the right thing to have built in the first place.

So the lever has to be re-pointed at the person rather than the machine. Batch size stops being a question of how much code goes out together and becomes a question of how much a single human being can take in, which is to say how much they can review, understand, integrate, and be willing to put their own name to. In the same way, work in progress is no longer something you sensibly count in tickets on a board; you count it in units of human attention, in the number of things one person can hold and remain accountable for at any given time.

The sharpest example of this I have come across was an engineer sitting with ten open pull requests, every one of them generated, every one of them passing its checks, and nowhere near enough time to look at any single one with the care it deserved. The board happily reported ten things in progress, and the real number was one, because a single person had to read, understand, and ultimately stand behind all of it. The board had been measuring the wrong thing for weeks, and nobody had noticed.

Miss this and you have not removed the queue, only moved it. Shrink the coding down to a matter of hours while the reviewing and integrating still take days, and what you are left with is a steadily growing pile of small changes that nobody has yet reviewed or integrated. The bottleneck has just moved a little further down the line, to the one place you had quietly stopped paying attention to.

Spend the freed time on the team, not on more output

All of this frees something up. The hours a team once poured into maintaining the board, re-explaining work that had already shipped, and writing code by hand are simply available now, and where that freed time goes matters more than any of the cadence mechanics above.

What genuinely surprised me was how little of the team's character sped up alongside the delivery. The work got faster, and yet the way the team made its decisions, the amount of trust it carried, and the ease with which it could absorb a change without seizing up all stayed exactly where they were, because none of them had ever been a function of the tooling. And once the delivery is fast, those slower, human things become the limit on what the team can do; the team that does well in the end is the one whose ability to decide and to stay aligned keeps up with how quickly it has become able to build.

So take the capacity you have just freed up and spend it on what limits the team now, its judgment and its trust and the shared understanding it works from, rather than on the easier path of producing still more. Bank the new speed as raw output instead and you get a team that ships a little more each week while its ability to agree on what is even worth shipping slips steadily further behind, and that widening gap, between how quickly a team can build and how quickly it can agree on what to build, now does more than anything else to decide how the team fares. The sprint coming apart was never a delivery problem to be re-tooled around. It was a sign that the binding limit had moved, and a leader who keeps pouring energy into delivery speed is spending it on the part of the system that was already working.