Recommended Reading

Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

by Mik Kersten

This book introduces the Flow Framework, a structured approach to measuring and optimizing the flow of business value through software delivery pipelines using flow metrics and items.

Amazon

Flow Metrics: Aligning Engineering Delivery with Business Value

In high-growth technology organizations, engineering leaders often struggle to translate technical output into business outcomes. Traditional metrics like lines of code or commit frequency measure activity, while system-centric frameworks like DORA metrics focus on deployment capability.

Flow Metrics bridge this gap by measuring the flow of business value through the entire software delivery lifecycle. Popularized by Dr. Mik Kersten through the Flow Framework, these metrics treat software delivery as a continuous value stream rather than a series of disconnected projects. By measuring flow, CTOs can shift their organizations from project-oriented execution to product-based value delivery.

The Four Flow Items

To measure flow, we must first define what flows. The Flow Framework posits that all software delivery work is composed of exactly four Flow Items, each representing a mutually exclusive type of business value:

1. Features (Business Value): New capabilities or functional improvements that deliver value to customers. Business driver: Revenue and market growth.
2. Defects (Quality): Work related to fixing bugs, outages, and regressions. Business driver: Product quality and customer retention.
3. Risks (Compliance & Security): Work focused on security, privacy, regulatory compliance, and governance (e.g., patch management, compliance audits). Business driver: Risk mitigation and safety.
4. Debts (Future Velocity): Work targeting Technical Debt and architectural viability (e.g., code refactoring, infrastructure upgrades). Business driver: Future delivery speed and system sustainability.

The Flow Items Value Stream

The Five Flow Metrics

Once work is classified into Flow Items, you can track performance using five core metrics:

1. Flow Velocity

• What it measures: The number of Flow Items completed over a specific time period (throughput).
• CTO Utility: Indicates whether delivery is accelerating, decelerating, or stable. Crucially, it tracks velocity per item type, showing whether the team is shipping features or spending all their capacity fighting defects.
• Pragmatic tip: Never compare velocity across different teams. Use it to track a single team's historical trends.

2. Flow Time

• What it measures: The total elapsed time it takes for a Flow Item to go from active acceptance (start of work) to production deployment (completion). This includes both active development and waiting time.
• CTO Utility: Represents the true customer-facing lead time. If product management wants to know when a feature will ship, Flow Time provides the historical predictability.
• Contrast with DORA: While DORA's Lead Time for Changes measures the speed of the CI/CD pipeline (commit-to-production), Flow Time measures the entire journey (idea-to-production).

3. Flow Efficiency

• What it measures: The ratio of active development time to total Flow Time: $\text{Flow Efficiency} = \frac{\text{Active Time}}{\text{Active Time} + \text{Wait Time}}$
• CTO Utility: Highlights bottlenecks and handoffs. Often, a feature takes weeks to deliver not because developers are writing code slowly, but because the item spent 80% of its time waiting in queues (e.g., waiting for QA, security review, or product sign-off).
• Example: A Flow Efficiency of 15% means a ticket spends 85% of its lifecycle sitting idle, waiting for action.

4. Flow Load

• What it measures: The amount of Work in Progress (WIP)—the total number of Flow Items currently active or waiting within the value stream.
• CTO Utility: High Flow Load is a leading indicator of delivery slowdown. Overloading teams leads to excessive context-switching, cognitive fatigue, and a high Change Failure Rate.
• Pragmatic tip: Set strict WIP limits. To increase velocity, you must first limit the flow of incoming items.

5. Flow Distribution

• What it measures: The proportion of each Flow Item type completed over a given period (e.g., 60% Features, 10% Defects, 10% Risks, 20% Debts).
• CTO Utility: The ultimate tool for strategic capacity allocation. It forces product and engineering leadership to explicitly negotiate trade-offs. If you dedicate 100% of capacity to Features, your Debt and Defects will inevitably pile up, crashing future velocity.
• Example capacity allocations:
  • New Product Launch: 80% Features, 10% Defects, 5% Risks, 5% Debts.
  • System Stabilization Phase: 20% Features, 40% Defects, 10% Risks, 30% Debts.

Strategic Utility: Why CTOs Should Care

Shifting from Projects to Products

Traditional project management measures success by budget and milestones. But projects can be "on time and on budget" while delivering zero value. Flow Metrics focus on the continuous release of value, encouraging teams to optimize for customer impact and lifecycle sustainability.

Combatting Goodhart's Law

When you measure individual metrics (like commits or story points), developers adapt their behavior to optimize those numbers—often hurting code quality or collaboration (see Goodhart's Law). Flow Metrics are systems-level measurements. They look at end-to-end delivery, making them far harder to game and aligning engineering incentives with business goals.

Allocating Tech Debt Explicitly

Rather than begging for "refactoring sprints," a CTO can use Flow Distribution to demonstrate the impact of neglecting tech debt. Showing a CEO that Flow Velocity is dropping because Flow Distribution has been 98% Features and 2% Debts makes the business case for architectural investment immediately clear.

References

• Wikipedia: Value StreamWikipedia
• Internal Resources:
  • DORA Metrics — For measuring software delivery and operational capability.
  • SPACE Metrics — For a multidimensional view of developer productivity.
  • Goodhart's Law — Understanding the risks of metric gaming.
  • Technical Debt — Managing architectural interest and trade-offs.