What Flows Through a Software Value Stream – Defining the Four Types of Flow Work Items

This piece is the third entry in a four‑part translation of Mik Kersten’s blog "What Flows Through a Software Value Stream," where the author argues that software delivery should adopt the same rigor found in modern manufacturing value‑stream design.

To locate bottlenecks, teams first need a shared definition of what actually flows through the system; common metrics such as lines of code, story points, or deployment counts each capture only a slice of value and have notable limitations.

There is little consensus among senior IT leaders about the core flow, and unlike the automotive industry’s clear output metric (cars produced), software lacks a universally accepted production‑level measure; Donald Reinertsen’s lifecycle‑profit concept is presented as a possible analogue.

Productivity must be tied to market‑driven value, so defining the flow is a prerequisite for measuring productivity and pinpointing constraints.

The author identifies four "flow work items": (1) feature development and defect fixes, (2) security, compliance, and regulatory work defined by business analysts, (3) technical‑debt reduction, and (4) additional work that emerges from tool‑chain analysis, all of which are mutually exclusive and collectively exhaustive (MECE).

Analysis of 308 toolchains showed that every observed work item could be mapped to one of these four categories, providing a useful abstraction for examining software value streams from a business‑centric perspective.

Other frameworks such as Philippe Kruchten’s positive/negative and visible/invisible quadrants and SAFe’s notion of "enablers" are mentioned as complementary ways to classify work, but the four flow items remain the primary lens for this analysis.

Readers are encouraged to explore Kersten’s book "Project to Product" for a deeper dive into flow metrics and the transition from project‑centric to product‑centric delivery.