Forecasting Using Historical Throughput

Why historical throughput feels refreshingly simple

A lot of forecasting advice gets buried under formulas, point conversion debates, or charts that look more certain than the team really is. Historical throughput feels simpler because it starts with one practical question: how many comparable work items has the team actually been finishing over time?

That makes it attractive to Scrum teams, product people, and engineering managers alike. It sounds grounded because it uses real delivery history instead of theoretical capacity or optimistic guesses.

What historical throughput forecasting actually means

Historical throughput forecasting uses completed-item history as evidence for what future delivery may look like. If a team usually finishes a broadly comparable number of items in a given time window, that history can help create a believable range for upcoming work.

The important word is comparable. Throughput gets useful when the work is sliced in a reasonably consistent way. Without that, the count still looks clean, but the signal underneath it gets much weaker.

Why teams get this wrong

Teams often take the cleanest number from the past and quietly turn it into a promise about the future. That is where the method starts to drift. Historical throughput is evidence, not a guarantee, and the evidence gets distorted fast when the system changes.

• The team changed how it slices work, so old counts are no longer comparable.
• Support load, dependencies, or staffing changed, but the forecast still assumes the old pattern.
• Different work types got lumped into one sample, so the average hides important variation.
• A neat historical average gets treated like certainty instead of one input into a range.

What a healthier approach looks like

The healthier move is to treat historical throughput as a starting point, then stress-test it against current reality. Is the team still working in roughly the same way? Is the backlog sliced similarly enough? Is there unusual interrupt pressure, risky migration work, or dependency drag that makes the old sample less trustworthy?

When teams do that well, throughput forecasting becomes practical. It gives people a credible range and a better conversation. It stops being a simplistic item count and starts becoming a delivery signal with context attached.

When historical throughput is most useful

Historical throughput works especially well when the team already has relatively stable workflow behavior and reasonably comparable work items. That makes it a strong fit for teams that want a lighter forecasting approach without pretending they can skip uncertainty.

• Use it to create a likely range, not one exact completion date.
• Use it when the team has enough stable history to be worth learning from.
• Use it alongside capacity and known delivery risk, not instead of them.
• Use it to expose planning tradeoffs early, before the deadline turns political.

TL;DR

• Historical throughput forecasting uses finished-work history as evidence for future delivery ranges.
• It works best when the work is sliced consistently enough to stay comparable over time.
• Teams get into trouble when they turn a clean historical average into a promise.
• The safer approach is to combine historical throughput with current capacity, risk, and backlog reality.
• Historical throughput is most useful when the current system still behaves enough like the sample you are using.