Defining What Flows Through a Software Value Stream: The Four Types of Work Items

This piece, part of a four‑article series by Mik Kersten (author of Project to Product ), explores how the rigor of modern manufacturing can be introduced into the design of software delivery value streams.

To find bottlenecks in a production system, one must first understand what actually flows through it. Existing software delivery metrics such as lines of code, story points, or deployment counts each capture a facet of value flow but have limitations when considering end‑to‑end business value.

There is little consensus among senior IT leaders about what flows through a software value stream, yet answering this basic question is essential for applying lean principles to software delivery.

Most enterprise IT organizations lack a well‑defined production metric comparable to the clear output measure used in automobile manufacturing.

Donald Reinertsen’s concept of lifecycle profit, introduced in The Principles of Product Development Flow , highlights that metrics like LOC or daily deployments represent delivered value rather than the value itself, and without a shared definition of flow, true productivity cannot be measured.

Business leaders gauge productivity by market‑driven outcomes, but linking development activities to those outcomes remains an opaque art rather than a disciplined practice.

The analysis identifies four fundamental flow work items:

Customer‑pulled features and defect fixes, which must become part of the flow.

Security, compliance, and regulatory work defined by business analysts and driven internally.

Enabler work (architecture, infrastructure, and other supporting tasks) that enables new features, fixes, or debt reduction.

Technical‑debt reduction work, essential to maintain the health of the codebase and infrastructure.

These four categories obey the MECE principle: they are mutually exclusive and collectively exhaustive, meaning every work item in a software value stream belongs to exactly one of them.

Other perspectives, such as Philippe Kruchten’s “positive/negative × visible/invisible” quadrants and SAFe’s notion of enablers, provide finer‑grained classifications but ultimately map back to the four high‑level flow items.

By viewing software delivery through this business‑centric lens, organizations can better analyze value streams, uncover bottlenecks, and foster discussions that shift productivity measurement from completed work to delivered customer value.