How Flow Metrics Improve Engineering Performance

The Flow Framework website cites that only 16% of businesses release updates more than once a month. They suggest that most traditional businesses experience bottlenecks in software delivery prevent them from executing growth strategies.

The Flow Framework seeks to address this challenge — by measuring the business value moving through delivery pipelines, which helps identify opportunities to accelerate future value creation.

In this article, we’ll discuss Flow Metrics, how to measure them, and how they compare to other frameworks for measuring software development productivity.

Sections:

‍

Flow Metrics are a component of the Flow Framework created by Dr. Mik Kersten, who aimed to create an approach to managing software projects based on Value Stream Management (VSM).

Value stream management (VSM) helps teams deliver better customer experiences more efficiently. At its core, VSM focuses on answering the question: How quickly can we deliver what customers want?

This framework provides a systematic approach to measuring software delivery value streams, enabling organizations to assess whether their value streams adequately support intended business outcomes. When implemented well, VSM delivers 3 key benefits:

• Creates better user experiences that lead to positive feedback and word-of-mouth
• Speeds up delivery of customer-focused products, driving growth and competitiveness
• Boosts team engagement by helping everyone see how their work connects to the bigger picture

"VSM has the potential to completely transform the process of funding, building, managing, and maintaining software at scale," notes Forrester.

‍

There are 2 key components to the Flow Framework:

1. Flow Items
2. Flow Metrics

Let’s discuss each of them below.

Flow Items

In order to measure flow in product value streams, it’s important to first define what is flowing. In the Flow Framework, there are 4 units of work that matter to the business. These are known as Flow Items:

1. Features: New value added to drive a business result
2. Defects: Fixes for quality problems that affect the customer experience
3. Debts: Improvement of the software architecture and operational architecture
4. Risks: Work to address security, privacy, and compliance exposures

Each Flow Item is a unit of value that is being pulled through a value stream — either by an internal stakeholder (e.g., another team) or external stakeholder (e.g., customer). Ultimately, it’s something someone is willing to exchange economic value for — which can be money, time, or adoption.

To clarify the business value of each unit of work, we need to categorize the work into the above 4 categories. Once organizations focus on flow, it’s easier for them to prioritize essential work, including work related to modernization, infrastructure, and security.

Flow metrics

Now that we have defined the items which are flowing through the value stream — we can now describe the 5 metrics to evaluate the speed and quality of that flow.

Flow Velocity

Flow Velocity measures productivity by quantifying the acceleration of value delivery. It answers the question “Is value delivery accelerating?”.

Tracking your Flow Velocity over an extended period provides historical data so that teams can see if their delivery rates have improved. This data enables more precise estimates and forecasts regarding their capacity to deliver both work and value.

Flow Velocity operates independently of traditional metrics like size estimates, scope definitions, or Flow Item priorities. It assumes that business prioritization and value definition is complete and focuses purely on the end-to-end movement of Flow Items.

Some examples of factors that may affect Flow velocity are:

• releasing new features too frequently without giving end users adequate time to adapt
• encountering high volumes of non-defect support requests that drain developer capacity
• lacking clear communication about upcoming changes
• providing insufficient training for new workflows
• skewing the team’s workload towards defect resolution rather than feature delivery

Flow Efficiency

Flow Efficiency, derived from Flow Time, quantifies your team’s active work engagement during a specified period. It addresses a fundamental question: "Is upstream work holding up delivery?”

Flow Efficiency is a crucial metric for understanding developer productivity. It measures the ratio of active work time to total time spent on tasks.

Low Flow Efficiency indicates that work is spending significant time in waiting states. This creates a broader impact: more items accumulate in progress (increasing Flow Load), and queues grow longer throughout your value stream.

Using the Flow Efficiency metric, you can readily see excessive wait times and work to reduce or eliminate bottlenecks.

Flow Metrics: A Business Leader's Guide to Measuring What Matters in Software Delivery - Pg 6

Flow Time

Flow Time measures the duration between business stakeholder approval and completion of work. This metric encompasses the total progression time of work items through the delivery process.

In Lean manufacturing, there are two key metrics used for process improvement: lead and cycle time.

The distinction between Flow Time and Lead Time lies in their measurement focus - Flow Time measures end-user delivery duration, while Lead Time measures dev team’s progress.

The difference between Flow Time and Cycle Time is that:

• Cycle Time refers to the active work phase of your development process. It measures the time spent actually building and refining the feature (excluding the time in backlog as features are prioritized).
• Flow Time focuses on the overall time taken to deliver a unit of value from start to finish. It is a foundational metric that aligns both development and business teams.

As a metric, Flow Time can tell you if your acceleration investments are actually improving your time-to-value.

Flow Metrics: A Business Leader's Guide to Measuring What Matters in Software Delivery - Pg 8

Flow Load measures the quantity of items a team manages within its value stream, commonly known as Work in Progress (WIP). This metric addresses a critical question: “How much work is the team managing at any given time?”

By monitoring Flow Load, you can observe its impact on Flow Velocity and Flow Time, revealing the threshold where concurrent Flow Items begin to diminish overall output.

Excessive Flow Load correlates with reduced efficiency in your development process. As Donald Reinertsen notes in "The Principles of Product Development Flow," when WIP is high, queues are high.

Flow Metrics: A Business Leader's Guide to Measuring What Matters in Software Delivery - Pg 93.5 Flow Distribution

Flow Distribution is the proportion of the flow items currently in process—features, defects, risks, and debts. It answers the question: Are development efforts in line with business objectives?

Flow Distribution ensures you’re not sacrificing one area of focus in place of others. It’s a tool that allows you to quickly see how much time your team spends on feature work instead of addressing other issues that affect the overall quality and security of your applications.

As Dominica DeGrandis, author of Making Work Visible, puts it, "A decision to do one thing is a decision to delay something else.”

Flow Distribution can also be set for an entire organization in order to deliver a high-level business goal. Bill Gates did this, for example, with Microsoft’s Trustworthy Computing initiative, focusing the company on risk and security improvements. If your organization is under threat from a more nimble company, for example, you may want to move from an old platform to the cloud, and optimize software delivery to bring new features to customers rapidly.

Flow Metrics: A Business Leader's Guide to Measuring What Matters in Software Delivery - Pg 9

While every organization will have different priorities, here are a few strategies to improve your Flow Metrics:

1. Optimize Your Workflows — Streamline development by improving automation in your testing, deployments, and other repetitive tasks. Look for opportunities to simplify each step in your process to help work flow more smoothly through your pipeline. An example of this can be CI/CD — which will help your team ship changes to production faster and more reliably.
2. Keep Work in Progress (WIP) in Check — Build strong collaboration between your development, testing, and operations teams. When teams work closely together, they catch and solve problems faster. Make work visible to help everyone stay aligned, then set WIP limits to prevent bottlenecks and keep work moving efficiently.
3. Reduce Handoffs — Each time work moves between teams or departments, it creates potential delays. Keep work within a single team where possible, or clearly define handoff responsibilities. For example, involve QA early - they can write test scenarios before development starts, enabling developers to automate tests and optimize flow from the beginning.

‍

Flow Metrics aren’t the only way to measure developer productivity. There are numerous other productivity frameworks which can also be used, often times in conjunction.

In particular we’ll highlight DORA metrics — as these have evolved to become the industry standard for measuring developer productivity. Based on research spanning over 39,000 professionals across organizations of all sizes and industries, these 4 metrics have proven to be reliable predictors of organizational performance.

DORA

DORA and Flow Metrics serve different but complementary purposes. DORA focuses on developer productivity, while Flow Metrics emphasizes the value delivered to end-users. As a result, DORA can identify specific DevOps issues, such as inadequate testing or release pipeline instability, which may only be visible in aggregate form in Flow Metrics

DORA metrics, when first introduced by Google's DevOps Research and Assessment team, focused on 4 key metrics (”the four keys”) that are strong indicators of software delivery performance. This has evolved over time, with updates to a metric and an introduction of a 5th:

• Change Lead Time: The time it takes to go from first commit to code successfully running in production.
• Deployment Frequency: How often an organization deploys code to production or releases it to end users.
• Failed Deployment Recovery Time (Formerly Mean Time to Recovery): The time it takes to restore service when a deployment causes an outage or service failure in production (whereas previously Mean Time to Recovery also included uncontrollable failure events such as an earthquake disrupting service).
• Change Failure Rate: The percentage of changes that result in degraded service or require remediation (e.g., that lead to service impairment or outage, and require a hotfix, rollback, fix forward, or patch).
• Rework rate: This fifth metric was introduced later in 2024, and together with Change Failure Rate provide an indicator of software delivery stability. Since it's a newer addition, there aren’t yet established quantifiable benchmarks and so this metric tends to receive less focus.

SPACE

SPACE is closer to DORA than to Flow Metrics in that it focuses on developer activities, with an added emphasis on developer experience. Similar to DORA, SPACE can be used in conjunction with Flow Metrics to provide perceptual and workflow measurements that illuminate developer interactions with DevOps tools and processes.

The SPACE framework, proposed by Dr. Nicole Forsgren, Margaret-Anne Storey, and Chandra Maddila, takes a holistic view of developer satisfaction by considering 5 key dimensions:

• Satisfaction and Wellbeing: Measures satisfaction, fulfillment, and wellbeing, both at work and off work.
• Performance: Outcomes that the organization aims to reach or create value for customers and stakeholders.
• Activity: Combines outputs that are countable, discrete tasks and the time it takes to complete them.
• Communication and Collaboration: Represents the interactions, discussions, and other acts of collaboration that take place within teams.
• Efficiency and Flow: Focuses on the ability of a developer to complete work or make progress.

DevEx

Flow Metrics and the developer experience (DevEx) metrics framework represent distinct yet complementary methodologies for measuring and enhancing software development productivity.

Flow Metrics, which operates within the broader Flow Framework, evaluates how quickly and efficiently value reaches end users. In contrast, the DevEx metrics framework examines developers' day-to-day experiences and identifies the key elements that influence their satisfaction, productivity, and overall performance.

The DevEx Framework focuses on measuring the lived experience of developers and the points of friction they encounter in their everyday work. It aims to provide a holistic view of the developer experience by considering 3 key dimensions:

• Feedback Loops: The speed and quality of responses to developer actions
• Cognitive Load: The mental effort required to perform tasks
• Flow State: The ability to work with focus and enjoyment

‍

To effectively improve your flow metrics, teams can use Multitudes, an engineering insights platform for productivity and wellbeing. Multitudes integrates with your existing development tools, such as GitHub, PagerDuty and Jira, to provide insights into your team's productivity and collaboration patterns.

With Multitudes, you can:

• Automatically track all four key DORA metrics
• Get visibility into work patterns and where the team’s time went, e.g. into feature development vs. bug fixing
• Identify collaboration patterns and potential silos within your team
• Understand individual and team wellbeing through metrics like out-of-hours work, incidents, and meetings
• Integrate with Slack to receive automated nudges and strategies on how you can help your team take action for sustainable productivity

By leveraging Multitudes, teams can spend more time acting on insights to improve their productivity.

Ready to unlock happier, higher-performing teams?

Try Multitudes today!