Throughput in Agile: How to Calculate, Measure & Forecast It

Key Highlights of Throughput in Agile

• Throughput in Agile tells you how many work items a team completes in a defined period.
• Throughput is simply the number of work items completed divided by the time period.
• Throughput counts things that are done. Velocity tends to count estimated story points.
• Throughput works particularly well with Kanban and continuous-flow teams.
• Throughput is more useful when considered in conjunction with Cycle Time, WIP, and other Flow Metrics.
• Little's Law relates WIP, throughput, and cycle time.
• Teams can use past throughput data to make more realistic delivery forecasts.
• Throughput should be used to understand delivery flow, not as a target for individual productivity.

Introduction

Agile teams use metrics to understand how work moves from a request to a finished product. But not every metric answers the same question. Some metrics focus on time, some on estimated effort, and others on the amount of work that actually gets finished.

This is where throughput in Agile becomes useful.

Throughput is the number of work items a team finishes in a specific amount of time. The period could be a day, a week, a sprint, or a month. For example, if a team completes 18 user stories in three weeks, its average throughput is 6 items per week.

That sounds simple, and it is. The real value comes from what you do with the number.

A team can use throughput to see whether delivery is stable, whether a workflow is getting faster or slower, and whether its current delivery rate can support an upcoming deadline. It can also be combined with cycle time and WIP to get a better picture of the team's flow.

This makes throughput one of the usefulAgile Metricsfor teams that want to focus on actual delivery rather than only estimates.

What Is Throughput in Agile?

Definition: Items Completed per Time Period

Throughput Agile is the number of work items completed during a defined period.

The work item could be a user story, feature, bug, service request, task, or another unit that the team has agreed to count.

For example:

• 5 items completed in one week = 5 items per week
• 12 items completed in two weeks = 6 items per week
• 30 items completed in one month = 30 items per month

The important point is that the team counts finished items.

This is different from counting items that were started. If a team starts 20 items but finishes only 8, its throughput for that period is 8, not 20.

ProKanban defines throughput as the amount of work in progress completed per unit of time. The selected time unit can vary based on how the team works. 

Why Throughput Measures Actual Delivery

One reason why teams use the agile throughput metric is that it is based on something that actually happened.

A story can be estimated as 8 story points, but an estimate does not mean the work has been delivered. Throughput looks at what crossed the team's agreed 'done' point.

This gives teams a simple question to answer:

How much work are we actually finishing?

Suppose a team has estimated 40 story points for a sprint but finishes 25. Velocity may tell you that 25 points were completed. Throughput might tell you that 7 work items were completed.

Both numbers provide information, but they tell different stories.

Throughput is particularly helpful when work items are similar enough in size or when the team wants to study the flow of items without relying on story point estimates.

Where Throughput Sits Among Flow Metrics

Throughput is one part of a wider group of flow metrics.

Other useful measures include:

• Work in progress
• Cycle time
• Lead time
• Work item age
• Flow efficiency
• Flow distribution

Looking at only one number can hide important details.

For example, a team may increase throughput from 8 to 12 items per week. That sounds good. But if the team also has a large increase in defects or customer complaints, the higher number does not necessarily mean the process improved.

This is why throughput should be viewed alongside otherFlow Metrics. Together, they help teams understand what is happening inside the workflow.

The Throughput Formula

Counting Completed Items in a Time Window

The throughput formula Agile teams use is straightforward:

Throughput = Number of completed work items ÷ Time period

For example, a team completes 24 items in four weeks.

24/4 = 6 items per week

So the average throughput of the team is 6 per week.

Another team does 15 in three weeks:

15 ÷ 3 = 5 items each week

The calculation is simple. The harder part is getting the team to count items consistently.

Choosing the Right Unit and Cadence

The time period should match the way the team works.

For example, a support team that receives requests every day may want to measure throughput daily or weekly. A product team may find weekly throughput more useful. A larger delivery group may review throughput monthly.

There is no single correct time period.

What matters is consistency.

If you calculate throughput in weeks for one month and then switch to days without adjusting the calculation, comparisons become confusing.

It is also useful to avoid concluding a very small sample. One unusually busy week does not necessarily represent the team's normal delivery rate.

A longer history gives you a better view of normal variation.

Throughput vs Velocity

How They Differ in What They Count

The difference between throughput vs velocity Agile teams often discuss comes down to the unit being measured.

Velocityusually measures the amount of estimated work completed in an iteration. This is often expressed in Scrum as story points.

Throughput is the number of work items completed in a period of time.

For instance:

Team A

• 32 story points done in a sprint
• Velocity = 32 points

Team B

• 9 work items completed in 1 week
• Throughput = 9 items/week

Velocity is a function of estimation. Throughput does not.

Agile Alliance describes throughput as the number of work items entering Done per unit of time and contrasts it with velocity, which measures story points per iteration.

When to Use Each

Velocity can be a helpful metric for a Scrum team that has a stable way of estimating and is working in regular sprints. This can help with sprint planningand provide the team with a view of how much estimated work they generally get done.

Throughput can be useful when the main question is about delivery rate.

For example:

• How many requests do we finish each week?
• How many features do we normally release each month?
• How many tickets can this workflow complete?
• Has our delivery rate changed over time?

The two metrics do not have to compete with each other.

A Scrum team can track both. The important thing is knowing what each metric actually tells you.

Why Throughput Suits Kanban Teams

Throughput is particularly useful for throughput in Kanban teams because Kanban focuses heavily on continuous flow.

A Kanban team does not need to wait for the end of a sprint to ask how much work it is finishing. The team can look at completed items week by week.

This is one reason throughput appears regularly in discussions aboutKanban Metrics.

Kanban teams can combine throughput with cycle time, WIP, work item age, and other Kanban metrics to understand where work is slowing down.

Throughput and Little's Law

Throughput, WIP, and Cycle Time Together

Little's Law connects three important parts of a workflow:

Average WIP = Average Throughput × Average Cycle Time

It can also be rearranged as:

Average Throughput = Average WIP ÷ Average Cycle Time

For example, imagine that a team has:

• Average WIP = 20 items
• Average cycle time = 4 weeks

Then:

20 ÷ 4 = 5 items per week

The average throughput is 5 items per week.

Little's Law is based on relationships between averages in a stable system. It helps explain why WIP and cycle time should not be viewed separately from throughput. 

This is useful in day-to-day Agile work.

If a team keeps adding more work without finishing existing work, WIP increases. If throughput does not increase with it, cycle time can grow.

In simple terms, more work sitting in the system can mean more waiting.

Using Throughput to Forecast Delivery

Historical throughput can also support delivery forecasts.

Suppose a team has 40 remaining work items and usually completes between 8 and 12 items per week.

Instead of saying, "We will finish in exactly four weeks," the team can look at a range of possible outcomes.

At 8 items a week:

40 / 8 = 5 weeks

At 12 items/week:

40 / 12 = 3.33 weeks

That gives a rough ballpark of about 3 to 5 weeks.

It’s more honest than pretending the team is always going to deliver 10 items each week.

How to Measure Throughput Step by Step

Defining Done for Counting

Before measuring throughput, agree on what counts as completed, ideally using the team’sDefinition of Done.

For example, does an item count when:

• Is development finished?
• Is testing finished?
• Is code merged?
• Can the customer use it?
• It reaches the final Done column?

Pick one clear point and use it consistently.

If one week you count items after development and another week you count only items released to customers, your throughput data will not be reliable.

Collecting and Charting the Data

Start with a simple record.

For every time period, write down the number of items completed.

For example:

• Week 1: 7
• Week 2: 9
• Week 3: 6
• Week 4: 8
• Week 5: 10
• Week 6: 8

This gives an average of 8 items per week.

You can then put these numbers on a throughput run chart, or pair it with acumulative flow diagramto see where work accumulates.

A run chart makes variation easier to see. Instead of looking at one average, you can see whether delivery is fairly stable or whether the numbers move sharply from one period to another.

This is whereKanban Metrics can add useful context. Throughput becomes more meaningful when you compare it with cycle time and WIP.

Reading Throughput Run Charts

Do not look only for a rising line.

A stable line can be a positive sign because it suggests that the delivery system is predictable.

For example:

7, 8, 8, 9, 8, 7, 9

This team has fairly steady throughput.

Now compare it with:

3, 14, 2, 12, 4, 15, 1

The average may look acceptable, but delivery is highly uneven.

The second team may have batching, bottlenecks, blocked work, uneven work sizes, or other workflow problems.

The purpose of the chart is not to make the line go up every week. It is to help the team understand its delivery pattern.

Throughput Example (Worked)

Consider a software team working on product features and defects.

During six weeks, the team completes:

• Week 1: 8 items
• Week 2: 10 items
• Week 3: 7 items
• Week 4: 9 items
• Week 5: 11 items
• Week 6: 9 items

Total completed:

8 + 10 + 7 + 9 + 11 + 9 = 54 items

Average throughput:

54 ÷ 6 = 9 items per week

So, the team's average agile throughput calculation is 9 items per week.

Now imagine that 27 items remain in the backlog.

A very simple average-based forecast would be:

27 ÷ 9 = 3 weeks

But the team should not treat three weeks as a guaranteed date. Actual throughput changes from week to week.

The team's history ranges from 7 to 11 items per week. That variation matters.

This is why throughput works best when it is used with other flow metrics, rather than as a single promise about the future.

How to Improve Throughput

Limiting WIP and Reducing Bottlenecks

A common mistake is to assume that more work started means more work finished.

It often does not.

If five people are each working on several items, everyone may look busy while very few items reach Done.

Limiting WIP, one of thecore practices of Kanban, can help the team focus on finishing existing work before starting something new.

Little's Law also gives a useful way to understand the connection between WIP, cycle time, and throughput. 

The team can ask:

• Where is work waiting?
• Which column keeps filling up?
• Where do reviews get delayed?
• Are testing tasks becoming a queue?
• Are blocked items staying open too long?

Fixing a bottleneck can improve the flow of work without simply asking people to work harder.

Improving Flow Efficiency

Flow efficiency looks at how much time work is actively being worked on compared with how much time it spends waiting.

Suppose an item takes 10 days to move from start to Done. If the team spends only 3 days actively working on it and it waits for review, testing, approval, or another dependency for 7 days, there is a clear opportunity to improve the workflow.

This does not mean every waiting period can be removed.

Some waiting is normal.

The goal is to understand where waiting happens and whether it can be reduced.

This is another reason to reviewFlow Metricstogether rather than treating throughput as an isolated number.

Right-Sizing Work Items

Item size has a direct effect on how useful throughput is.

Imagine two teams:

Team A completes 10 small tasks each week.

Team B completes 4 large features each week.

You cannot say Team A is more productive simply because its throughput is higher.

The items are different.

This is one of the biggest limitations of throughput.

Teams get more useful results when work items are reasonably consistent in size or when throughput is combined with other information.

Breaking very large items into smaller, valuable pieces, using soundbacklog breakdown strategies, can also help work move through the system more regularly.

Using Throughput for Forecasting

Probabilistic Forecasting Instead of Estimates

Throughput forecasting Agile teams use can be more realistic when it accounts for variation.

Instead of saying:

"We complete 10 items every week, so 50 items will take exactly five weeks."

A team can look at its historical range and ask:

"What does our past data suggest about the likely delivery range?"

This approach accepts that delivery is not perfectly predictable.

Some weeks will be better than others. A production issue may reduce delivery. A dependency may block several items. A small number of larger tasks may take longer than expected.

Historical throughput helps bring this variation into the discussion.

Monte Carlo Basics for Scrum Masters

Monte Carlo forecasting uses past delivery data to model many possible future outcomes.

A Scrum Master or Agile coach can use historical throughput values to simulate different delivery sequences.

For example, if recent weekly throughput has been:

7, 8, 9, 10, 11, 8, 9, 12

A forecasting model can repeatedly select values from that history to estimate how long it may take to complete a given number of items.

The result is not a guaranteed date.

Instead, it can answer questions such as:

• What is the chance of finishing 30 items within four weeks?
• How many items might we complete in six weeks?
• How much time should we allow if we want a higher level of confidence?

This is much more useful than turning an average into a false promise.

Common Mistakes to Avoid

Treating Throughput as a Productivity Target

Throughput should not become a personal target.

If a manager tells a team, "You must complete 15 items every week," people may start looking for ways to increase the number rather than improve the actual system.

They may break work into too small pieces, avoid doing larger work, rush through testing, or move incomplete work into Done.

That can make the metric look better while delivery quality gets worse.

Use throughput as a measure of the system, not as a score for individual team members.

Ignoring Item Size Variability

Ten tiny bugs and ten major product features are not the same amount of work.

Throughput does not show item size by itself.

That’s why throughput is not the only thing teams should use to judge output. Combine it with cycle time, WIP, quality data, and business outcomes.

For a broader view of Agile measurements, teams can also refer to Top 10 Agile Metrics.

The Scrum Master's Role and Best Practices

A Scrum Master can help the team use throughput in a sensible way.

The first step is to get everyone on the same page as to what counts as Done. Without that agreement, the numbers will not mean much.

The Scrum Master can then help the team collect throughput data regularly and look for patterns.

Some useful questions include:

• Is our throughput stable?
• Where does work wait?
• Has WIP increased?
• Has cycle time changed?
• Are certain types of work taking longer?
• Are blocked items affecting delivery?
• Are we starting too much work?
• Are we using the metric to improve the system or to judge people?

A Scrum Master should also avoid turning every change in throughput into a problem.

A drop from 10 items to 8 items in one week doesn’t automatically mean the team is doing badly. It could be a holiday, a production issue, a complex feature, a dependency, or something else.

The goal is to look for patterns over time.

SAFe Scrum Master Certification Training can also help Scrum Masters who are working in larger Agile environments build a stronger understanding of team facilitation, flow, and delivery practices. The current training covers areas such as team facilitation, Scrum Master responsibilities, and Agile practices in a scaled environment.

Most importantly, remember that metrics should start conversations.

They should not end them.

A throughput chart can tell you that delivery changed. The team's job is to understand why.

Conclusion

Throughput Agile teams use is one of the simplest delivery metrics to calculate. It tells you how many work items were completed during a specific period.

The basic formula is:

Throughput = Completed work items ÷ Time period

But the value of throughput goes beyond this calculation.

Combining throughput, WIP, and cycle time gives teams a better understanding of how work moves through the system. Little's Law helps connect these measures and shows why changes in WIP, throughput, and cycle time are closely related.

Throughput is especially helpful for Kanban and continuous-flow teams, as it is not based on story points or fixed sprints. It can also aid in forecasting when teams use historical data, rather than assuming delivery will always be the same.

The main thing to remember is simple: throughput is about finished work.

Use it to understand the system, find bottlenecks, improve flow, and make better forecasts. Do not turn it into a productivity contest.