Throughput

Definition & formula

work completed / [unit of time]

Work delivered for a given period of time.

The Socratic view

Two key points with this one.

First, knowing how much work you delivered in a given period, by itself, is fairly meaningless. Is ten good? A hundred? A thousand? What we're really interested in is the number of tasks we completed, relative to the number of new tasks raised. Ten tasks completed is actually a good number, if the number of new tasks raised over the same period was, say, seven. This tells us that delivery is outpacing demand.

Second, don't worry about the fact that work items may vary in size or complexity. It doesn't matter. Why not? The law of large numbers (LLN). Over the course of enough tasks, the inevitable differences in size among them basically come out in the wash.

Background

It originated from the Lean software development framework, which emphasizes delivering value to customers efficiently. The concept of throughput gained popularity in the software industry during the early 2000s.

The Lean framework focuses on eliminating waste and maximizing efficiency in software development processes. Throughput emerged as a key metric to assess the productivity and effectiveness of software engineering teams. By measuring the rate at which tasks are completed, teams can evaluate their delivery capability and identify areas for improvement.

Use cases

Throughput is widely used in the software engineering industry to monitor and optimize team performance. Development teams, project managers, and stakeholders utilize this metric to gain insights into the efficiency of their processes. It allows them to assess how well the team is delivering value to customers and meeting project goals.

Teams often track throughput to identify bottlenecks in their workflow and improve overall productivity. By analyzing the relationship between completed tasks and the number of new tasks raised, teams can understand whether they are keeping up with demand. Throughput also helps in capacity planning, resource allocation, and setting realistic project expectations.

Evaluating the metric

A good value for throughput depends on the context and specific project requirements. Generally, a higher throughput indicates greater efficiency and productivity. It suggests that the team is effectively completing tasks and delivering value to customers.

On the other hand, a low throughput may indicate potential issues in the software engineering process. It could imply that the team is struggling to keep up with the demand or facing challenges in task completion. Low throughput might also suggest inefficiencies, such as bottlenecks or resource constraints.

Evaluating the metric requires considering the project scope, team size, and complexity of tasks. It is essential to establish baseline measurements and track throughput consistently over time. By analyzing trends and comparing with industry benchmarks, teams can identify areas for improvement and implement strategies to optimize their throughput.