One Piece Flow in Software Delivery

In 1948, Taiichi Ohno started building what would become the Toyota Production System. One of its core ideas was one piece flow - moving a single unit through the entire production process before starting the next one. No batching. No inventory piles between stations. One in, one through, one out.

The principle transformed manufacturing. And then software people borrowed it, and most of them got it wrong.

What one piece flow actually is

One piece flow is not about speed. It is about reducing work in progress to expose problems immediately. When you process items one at a time, every defect surfaces at the station that created it. There is no buffer to hide behind. The feedback loop between cause and consequence is as short as physics allows.

In manufacturing, this works because the inputs are uniform, the stations are balanced, and the operations are repeatable. A car door is a car door. The variance is low. The system can be tuned until flow is continuous.

Ohno’s insight was that batch-and-queue production - the dominant model at the time - was not actually efficient. It looked efficient because every station stayed busy. But the system as a whole was slow, because inventory sat in queues between stations, hiding defects and delaying feedback. The local optimization of keeping every station utilized created a global problem: long lead times, late defect discovery, and massive rework.

One piece flow solved this by making the system’s lead time the thing you optimize, not any individual station’s utilization.

The math that matters

In 1961, MIT professor John Little proved a formula that now bears his name:

Cycle Time = Work in Progress / Throughput

This is not a heuristic. It is a mathematical law, proven to hold for any stable system observed over sufficient time. It says: if your throughput stays constant, reducing WIP reduces cycle time proportionally. Cut your WIP in half, cut your cycle time in half.

Donald Reinertsen extended this into product development with The Principles of Product Development Flow (2009), applying queueing theory to show that batch size is the single most important lever for improving flow. Smaller batches mean shorter queues, shorter queues mean shorter cycle times, and shorter cycle times mean faster feedback. He also introduced a concept most teams still ignore: the cost of delay - the economic damage caused by each unit of time a feature sits undelivered. Only 15% of product development teams know their cost of delay. The rest are optimizing blind.

DORA’s decade of research confirmed this empirically. Deployment frequency - which is a proxy for batch size - correlates with every positive outcome they measure. Elite performers deploy on demand with small changes. They also have lower change failure rates and faster recovery times. Speed and stability are not a tradeoff. They are the same thing, measured at different points.

Where the metaphor breaks

Here is the problem: software is not a car door.

In manufacturing, a unit of work has uniform inputs and outputs. The variance is low. A station does the same operation thousands of times. One piece flow works because the system can be balanced - every station takes roughly the same time, so units move smoothly without accumulating queues.

Software has almost none of these properties. Every story is different. Inputs are ambiguous. Outputs are novel. The “stations” (design, implementation, review, testing, deployment) take wildly different amounts of time depending on the work. The variance is high, and high variance breaks the assumptions that make one piece flow elegant in manufacturing.

An empirical study published by ACM/IEEE examined over 8,000 work items across five teams over four years. The finding that supports the literature: lower WIP correlated with shorter lead times. The finding that complicates it: lower WIP also correlated with lower productivity. The teams got things through faster, but they got fewer things through. The relationship between WIP, speed, and output is not as simple as Little’s Law makes it look when variability is high.

A separate experiment found that teams working with appropriately-sized story batches outperformed strict one-piece-flow teams by 26%. The reason was not that bigger batches are inherently better. It was that teams with properly scoped stories had spent time discussing the overall story - the theme, the approach, the dependencies. They understood what they were building and why. They self-organized more effectively, helped each other more, and produced fewer defects.

The one-piece-flow teams, working on maximally decomposed atomic units, lacked that shared understanding. They completed individual tasks quickly but spent more time on rework, coordination, and rediscovery of context that had been stripped out by over-decomposition.

The real unit of flow

This is the insight most teams miss: the unit of flow in software is not a commit. It is a well-sized story.

A commit is a code change. A story is a unit of value delivery. These are not the same thing. A commit can be atomic, well-tested, and individually meaningless. A story delivers something a user or a system can actually use - a capability, a behavior, an outcome.

The one piece flow principle, applied correctly to software, does not mean “send the smallest possible commit to production as fast as possible.” It means: move one well-understood unit of value through the entire delivery pipeline before pulling the next one. Finish what you started. Do not start what you cannot finish.

This has implications for how you size work.

A well-sized story is:

  • Small enough to flow. It can move from design through deployment in days, not weeks. It does not accumulate in queues. It does not age in review. The team can hold the entire scope in their heads.

  • Large enough to cohere. It delivers a complete behavior, not a fragment. It does not require three other stories to ship before it means anything. A reviewer can understand why this change exists without reading a Jira epic.

  • Well enough understood to execute without rediscovery. The team has discussed the approach, the edge cases, the dependencies. Not in a 90-minute refinement meeting - in a focused conversation that produces shared context. This upfront investment pays for itself in reduced rework, reduced coordination overhead, and reduced context switching during execution.

The cost of this preparation is real. A well-sized story takes more time to define than an atomic task. It requires the team to think before they type. In a culture that measures velocity by tickets closed, this looks like waste. It is the opposite of waste. It is the investment that makes flow possible.

What the research supports

Here is what the evidence base actually says, organized by strength:

Strong evidence (replicated across multiple studies and years):

  • Smaller batch sizes correlate with shorter cycle times and lower defect rates. This is supported by DORA’s longitudinal data, Reinertsen’s queueing theory analysis, and multiple manufacturing studies. The mechanism is well-understood: shorter feedback loops catch problems earlier.

  • Lower WIP correlates with shorter lead times. This is mathematically guaranteed by Little’s Law under stable conditions and empirically confirmed by DORA and the ACM/IEEE kanban study.

  • Context switching is expensive for developers. The APA’s research on task-switching costs, multiple Microsoft studies, and practitioner surveys consistently show 15-30 minutes of recovery time per interruption. Fewer items in flight means less switching.

  • Trunk-based development with small, frequent merges outperforms long-lived feature branches. DORA’s 2016-2017 data shows teams with three or fewer active branches and daily merges significantly outperform on all delivery metrics.

Moderate evidence (supported but with caveats):

  • Reducing WIP improves productivity. The ACM/IEEE kanban study found the opposite in some conditions - lower WIP correlated with lower throughput. The relationship depends on the type of work, team structure, and how “productivity” is measured. This is the caveat that most one-piece-flow advocates skip.

  • Appropriately-sized batches outperform maximally-decomposed ones. The 26% improvement finding is from a single experiment with limited sample size. It is consistent with cognitive load theory and practitioner experience, but it has not been replicated at scale.

Weak evidence (claimed but not well-supported):

  • There is an objectively optimal WIP limit for software teams. No published study from real cases identifies one. The commonly cited “2/3 to 3/4 of team size” comes from simulation exercises, not production data. The right WIP limit is context-dependent and must be discovered empirically by each team.

  • One piece flow, literally applied, works for software. Even in manufacturing, it requires perfect line balance - every station must take the same time. Software development has no such balance. The principle must be adapted, not transplanted.

Practical application

If you take one thing from this: stop optimizing for small commits and start optimizing for well-understood stories that flow.

Concretely:

Invest in story preparation. The cheapest time to prevent rework is before the first line of code. A thirty-minute conversation between the author, a reviewer, and a domain expert that surfaces edge cases, clarifies scope, and establishes the approach will save hours of mid-flight rework and days of review ping-pong. This is not waterfall. This is buying shared understanding before execution starts.

Limit work in progress at the story level, not the task level. If your team has four developers, limit active stories to two or three - not two or three tasks each. The goal is for the team to focus on finishing a small number of stories rather than starting a large number of tasks. Swarming - multiple developers collaborating on one story - is the one piece flow pattern that actually works in software.

Make the flow visible. If you cannot see where stories are stuck, you cannot improve flow. A board with columns for “ready,” “in progress,” “in review,” and “deployed” is not a project management ritual. It is the equivalent of the manufacturing floor layout that makes queues visible. When you see two stories aging in review and three more waiting to start, the problem is obvious. When all you see is a sprint burndown, it is not.

Measure cycle time, not velocity. Velocity counts the volume of work completed per sprint. Cycle time measures how long each unit of work takes from start to finish. Velocity rewards starting things. Cycle time rewards finishing them. One piece flow is about finishing.

Treat aging work as a defect. In one piece flow manufacturing, a unit stuck at a station triggers a stop-the-line response. In software, a story that has been “in progress” for a week is the equivalent. It is not a sign of complexity. It is a sign that something went wrong - the scope was unclear, the approach hit a wall, a dependency was invisible, or review capacity is a bottleneck. Surface it. Fix it. Do not let it age silently.

The honest summary

One piece flow is the right principle applied at the wrong level of abstraction by most software teams.

The insight is real: reducing work in progress, shrinking batch sizes, and optimizing for system lead time over station utilization produces better outcomes. Forty years of manufacturing data and a decade of DORA research confirm this.

But the unit of flow matters. In manufacturing, it is a physical object. In software, it is a unit of delivered value - a story that a team understands, can execute without rediscovery, and can ship in days. Not a commit. Not an atomic task. Not a ticket.

The teams that get the most from this principle are not the ones deploying the most frequently. They are the ones that invest in understanding their work before they start it, focus on finishing before starting, and measure how long value takes to reach users - not how many story points they closed.

That is what one piece flow means in software. Not one commit at a time. One understood thing at a time, all the way through.

Sources