How Flow Metrics Improve Engineering Performance

Engineers spend only 8% of their time producing deliverable work. And while 60% of tech companies release more than once a month, out of "traditional businesses" 16% release updates more than once a month. They suggest that most traditional businesses experience bottlenecks in software delivery that prevent them from growing faster, to the point where they're at risk of being left behind by the top performers .

The Flow Framework seeks to address this challenge by linking software development activity to the business value created. This framework specifically links software development work to outcomes and shows where investments can help teams deliver faster.

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:

‍

The Flow Framework came from a bestselling book by Dr. Mik Kersten called Project to Product, which guides organizations to shift from project thinking, where they're looking at many one-off initiatives, to product thinking, where software is seen as a set of long-lived value streams. One of the goals of this framework is to give a shared language to technology and business leaders.

In the book, Dr. Kersten introduces the Flow Framework, which shows where work is flowing or not in the product value streams so that leaders can find and address bottlenecks. To enable that, the Flow Framework provides a structured way to do Value Stream Management (VSM) in organizations delivering software. Value stream management (VSM) helps teams deliver better customer experiences more efficiently – by removing the things that block the flow of software development. At its core, VSM focuses on answering the question: How quickly can we deliver what customers want?

The Flow Framework provides a systematic approach to measuring software delivery value streams, enabling organizations to assess whether their value streams adequately support the intended business outcomes. When implemented well, VSM delivers 3 key benefits – it:

• 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

‍

As mentioned above, the Flow Framework is a value stream mapping technique. Value Stream Mapping (VSM) helps teams see how work flows from idea to production, making it easier to spot bottlenecks and opportunities for improvement. Think of it like creating a detailed map of your software delivery journey - you can't optimize what you can't see.While manufacturing uses VSM to track physical materials, in software development we're mapping how ideas transform into working features. DORA research highlights how VSM can be used in software delivery to drive better team performance.

‍Why VSM drives better results:

• Creates shared understanding - when teams can see the whole picture, conversations about improving delivery become more focused and productive
• Makes bottlenecks visible - rather than guessing where slowdowns happen, VSM helps pinpoint exactly where work gets stuck
• Enables data-driven improvements - by measuring flow at each stage, teams can verify whether changes actually make things better

Beyond improving processes, VSM helps build organizational memory. Having a clear record of how your development process has evolved helps teams learn from past improvements and builds confidence in continuing to optimize delivery.

Define your outcomes before blindly implementing the framework

Before diving into value stream mapping, take a step back and ask: what outcomes really matter? While there are countless things you could improve, focusing on changes that drive strategic goals is what separates effective transformation from busywork. Process improvements in isolation, no matter how well-intentioned, risk becoming expensive detours if they don't align with your organization's strategic direction.Here's a practical approach suggested by DORA to defining meaningful outcomes with your team:

• Bring together a small group of key stakeholders (aim for 8-10 people)
• Start by clarifying the strategic goals you need to accomplish
• Run focused brainstorming sessions to surface concerns and opportunities (try 5-minute timeboxes to maintain momentum)

Once you've gathered input, help the group converge on the most critical outcomes. A simple but effective approach is to:

1. Group similar ideas together
2. Vote on top priorities
3. Reframe chosen priorities as clear outcomes
4. Validate that these outcomes support your strategic goals
5. Document the expected benefits, potential obstacles, and immediate next steps

When defining outcomes, be specific and measurable. For example, instead of a vague goal like "improve team collaboration" or "speed up development", set concrete targets such as "reduce average code review response time from 24 hours to 8 hours within the next quarter.”

‍

There are 2 key components to the Flow Framework:

1. Flow Items – there are 4 of these: features, defects, debt, and risk. These are all parts of the software development lifecycle that we care about.
2. Flow Metrics – there are 5 of these: velocity, time, efficiency, load, and distribution (some organizations also use a sixth metric, predictability from the Scaled Agile Framework, SAFe). These metrics show us how well we're doing with our software development.

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 (via new or changed code) to drive a business result. This is the item most obviously linked to business success.
2. Defects: Fixes for quality problems that affect the customer experience. The focus here is on what we did to improve quality.
3. Debts (or technical debt): Improvement of the software architecture and operational architecture. This can take time away from feature development today, but can also make it faster to do software development in the future.
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 an external stakeholder (e.g., a customer). Ultimately, it’s something someone is willing to give something up in order to get; this can  be money, time, or adoption (which requires time and learning).To clarify the business value of each unit of work, we need to categorize the work into the above 4 categories.

Flow metrics

Now that we have defined the items which are flowing through the value stream, we can 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?”.

The formula for Flow Velocity is

‍Flow Velocity = Number of Completed Work Items / Time Period

‍Note that Flow Velocity counts ALL flow items completed, so not just feature work but also debugging work (defects), technical debt work, and risks work.

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 the business prioritization and value definition are accurate 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 allowing users time to adapt: Rapid-fire releases can overwhelm users, leading to confusion and a surge in support requests. As developers get pulled away from planned work to handle these issues, their capacity for building new features decreases, ultimately reducing Flow Velocity.
• High volumes of non-defect support requests draining developer capacity: When developers spend excessive time addressing support requests—even those unrelated to defects—their ability to work on planned development tasks diminishes. This directly impacts Flow Velocity by diverting resources away from delivering new value.
• Lack of clear communication about upcoming changes: Poorly communicated updates cause misalignment among teams and stakeholders, often leading to rework and unexpected delays. These disruptions slow the development cycle and negatively impact Flow Velocity by creating inefficiencies and bottlenecks.
• Insufficient training on new workflows: When team members aren’t properly trained on new workflows or tools, they struggle to complete tasks efficiently. This learning curve slows down development and reduces Flow Velocity by increasing the time required to deliver work.

‍‍

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.

The formula for Flow Time is:

‍Flow Time = Work in Progress (WIP) × Cycle Time

‍In Lean manufacturing, there are two key metrics used for process improvement: Lead Time and Cycle Time. In software development, the two key metrics are Change Lead Time and Cycle Time.

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 – from when the ticket was started until it was marked as done. This excludes the time spent in designing features and the time spent in backlog as features are prioritized.

Change Lead Time, which came out of the DORA metrics, is even narrower – it starts from when coding begins until it ends.

‍

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 slowing down our 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.

‍Flow Efficiency (%) =( Active Time / Total Flow Time) × 100

‍David J Anderson from Kanban University says that a good flow efficiency is anything above 40%

‍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; see definition below), and queues grow longer throughout your value stream.

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

‍

Flow Load

‍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?”

‍Flow Load = Number of Active Work Items

‍By monitoring Flow Load, you can observe its impact on Flow Velocity and Flow Time, revealing the threshold where having more Work in Progress starts to diminish the team's 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 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 order to achieve others. It’s a metric 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.The formula is:

‍Flow Distribution(%)=(Number of Completed Items of Type / Total Number of Completed Items) × 100

‍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.

‍

Once organizations focus on flow, it’s easier for them to prioritize essential work, including work related to modernization, infrastructure, and security.

But Flow Metrics aren’t the only way to measure developer productivity. There are many other software productivity frameworks which can also be used, sometimes in conjunction.

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

DORA and Flow Metrics serve different but complementary purposes. Both metrics focus on the value delivered to end users – this is evident in the Flow Metrics' link to business value and DORA's focus on creating customer value. However, DORA goes deeper into specific software delivery and operations practices. 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. This is a subset of Flow Time.
• Deployment Frequency: How often an organization deploys code to production or releases it to end users. There are analogies between this and Flow Velocity, since both look at value delivered, but Flow Velocity is a broader way to look at value delivered.
• 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). For this (and Change Failure Rate, following), there's not a clear parallel in the Flow Metrics, because the Flow Metrics focus on delivery of value, not what happens after it gets delivered.
• 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). Again, there's no parallel in the Flow Metrics because this is looking at what happens after the delivery of value.

Flow Framework and the 4 DORA metrics

Software teams operate with two essential value streams when delivering code to production. Understanding both is crucial for optimizing your delivery performance.

‍The Feature Delivery Value Stream

‍This is your standard deployment pipeline where planned changes flow to production - new features, improvements, and scheduled fixes. What’s considered DORA's throughput keys measure the efficiency of this path:

• Lead time (speed of changes through your pipeline)
• Deployment frequency (cadence of production deployments)

The Recovery Value StreamThis is your incident response pipeline - the critical path for deploying urgent fixes when issues occur. DORA's stability keys help measure the effectiveness of this stream:

• Change failure rate (percentage of deployments causing incidents)
• Failed deployment recovery time (speed of incident resolution)

While teams naturally focus on optimizing their feature delivery, the recovery value stream deserves equal attention. The volume of work flowing through this path is your change failure rate multiplied by deployment frequency. As you increase deployment frequency, maintaining a low change failure rate becomes even more critical.

The goal is to minimize the need for the recovery stream while ensuring it's highly efficient when needed. This means investing in practices that reduce failure rates while simultaneously optimizing your incident response process.Below is a diagram on how the four keys map to the value stream.

‍

To improve software delivery performance teams can use Multitudes, which is an engineering insights platform for sustainable delivery. Multitudes integrates with your existing development tools, such as GitHub and Jira, to provide insights into your team's productivity and collaboration patterns.

With Multitudes, you can:

• Automatically track your developer velocity with 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 well-being through metrics like out-of-hours work, incidents, and meetings
• Integrate with Slack to give you automated nudges and strategies on exactly what you should do next to improve team performance

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

‍Our clients ship 25% faster without sacrificing code quality.

Ready to unlock happier, higher-performing teams?

‍Try Multitudes today!