How two metrics led us to a 50% increase in team's throughput

The right metric used correctly is a powerful tool. Here's how metrics analysis helped a financial corporation identify a bottleneck that was causing a 30% performance loss.



Fintech corporation

scope of work

Process analysis & optimization






Agile Coach

  • lack of transparency and predictability in the process

  • insufficient data to support planning and decision-making

  • entry-level metrics configuration & analysis — Cycle Time & throughput

  • applying fixes to identified bottlenecks — reorganization of priorities to shorten the Code Review phase


THROUGHPUT (avg. number of tasks delivered in an interval)


Improving the transparency and predictability of the value delivery process

When the client approached us, their team was using Kanban for product delivery. While the process was well-organized, stakeholders struggled with two problems:

  1. Determining team’s efficiency in delivering value.

  2. Creating data-driven plans for the product’s development ahead.

Our goal was to increase the transparency of the process and optimize how much value gets delivered with each interval.


Measuring process efficiency with Cycle Time and throughput

To help the organization measure its product development efficiency and improve predictability, we decided to look at two metrics:

  • Cycle Time

  • throughput

We began with these two because they’ll be crucial for understanding the more advanced metrics in the future.

Our goal was to identify the bottlenecks in the process — redundant activities, drops in quality or slow-downs — and apply improvements to make the team’s work more efficient.

Cycle Time — How quickly tasks are completed

Cycle Time measures the average time it takes for the majority of tasks to get completed (from the moment they are started until they are marked as done.)

In the chart below, we can see that in our client’s case 87% of tasks were completed within 3 weeks:

In this Cycle Time graph, we can see that 87% of the tasks were typically completed in 3 weeks.

In Cycle Time analysis, it’s optimal to take into account around 85% of the tasks to exclude unusual cases and obtain accurate data for forecasting and planning.

Throughput — How many tasks are completed in an interval

Throughput measures the average number of tasks that get completed within any period of a given length.

It’s the number of tasks that fall within the 85% target in the Cycle Time analysis.

Based on the chart below we could tell that during any randomly picked 3-week period, the team typically delivered 15 tasks that took 3 weeks to complete or less.

Throughput analysis showed that the team typically delivered 15 tasks during  any randomly chosen 3-week period.

Interpreting data to fix bottlenecks and optimize the process

Once we gathered the necessary data it was time to put them in context. We met with the team to see what process improvements we could implement.

Upon closer examination of our Cycle Time, we noticed that 75% of tasks (32 out of 42) took 7-13 days to move from Code Review to the next stage.

Closer examination of Cycle Time revealed that 75% of the tasks spent from 7-13 in the Code Review stage.

Since this part of the process was completely within the team's control, they were able to address the issue on the spot.

Together, we implemented two simple improvements:

  • Every developer committed to beginning each day by performing code review of other developers' pull requests.

  • The whole team started prioritizing finding code reviewers during daily stand-ups.

What was the impact of these improvements?

What we’ve accomplished

Small fixes brought +50% throughput increase

By adding a single item to the daily meeting agenda and making a simple adjustment to developers' schedules, we saw the following results:

  • reduced Cycle Time — from 3 weeks to 1-2 weeks,

  • improved throughput — from 15 tasks in 3 weeks, to 15 tasks in 2 weeks (= 50% increase in the number of tasks completed in a comparable period).

None of the team members had to work overtime, and no one had to do more in a day than they normally would.The team was simply focusing on fewer tasks at once, and that meant:

  • fewer open tasks at once,

  • reduced context switching,

  • reduced risk of conflicting changes (when tasks were waiting to be merged.)

These small, yet effective changes are the type of observations and adjustments we should constantly be looking for to optimize how we manage our resources.

Data-driven planning became possible

Metrics are powerful tools for both teams and stakeholders.

By having access to these metrics, the team was able to identify barriers and effectively self-manage their processes.

At the same time, business stakeholders were finally able to see how quickly increments were being delivered, which made the process transparent and predictable.

This enabled them to make more informed decisions about the future of their products and plan development more effectively.

With information on task completion time (Cycle Time) and the number of items that can be delivered in a given period (throughput), they were able to easily determine which increments were feasible and which were not.

A good start, but not the end of the journey

What could the team do next?

Now that a solid foundation has been established, the team can begin using more advanced metrics to further analyze their processes.

One metric that could be particularly useful in scaling the analysis is Customer Lead Time, which measures the duration from the moment a feature is conceived to its release for the user.

By measuring and optimizing the Customer Leader Time businesses catn gain the edge over their competitors, draw new people to their products, and improve the engagement of the existing customer base.