Backlog Arrival Rate Forecaster

Here's the slow-motion disaster I've watched unfold at multiple companies: a team processes 50 items per month. New items arrive at 52 per month. Nobody notices because the difference is tiny — just two extra items. But after six months, the backlog has grown by 12 items. After a year, 24. Each one represents a stakeholder who expected their request to be done by now. The team feels the pressure mounting but can't explain why, because their velocity looks fine. The problem isn't throughput. It's that arrival rate quietly outpaced it. Forecasting fixes this by giving you early warning. If the trend line shows arrivals growing at 5% per month, you can see exactly when throughput won't keep up — and start the conversation about hiring, scope reduction, or process changes before the backlog becomes a crisis. Without a forecast, you're flying blind. You discover demand growth only when the backlog is already unmanageable, and by then your options are limited to heroics and apologies. Neither scales well. The teams I've seen handle this best treat arrival rate forecasting as a quarterly ritual — 30 minutes with a spreadsheet (or this tool) that buys them months of proactive planning instead of reactive scrambling.

Don't let the name scare you. The core idea is simple: your data is made up of three things multiplied together. There's a trend — is demand generally going up, down, or staying flat over time? The tool figures this out with basic linear regression on your deseasonalized data. Then there are seasonal factors — recurring patterns that repeat on a cycle. Maybe January is always high because budgets refresh. Maybe August is always low because half the team is on vacation. Each period in your cycle gets a factor: above 1.0 means above-average demand, below 1.0 means below-average. And finally there's the residual — random noise the model can't explain. One-off events, unexpected customer requests, that week everything broke because of a DNS issue. You can't predict residuals, and that's okay. The model doesn't try. To forecast, it just projects the trend forward and multiplies by the appropriate seasonal factor. So if the trend says "expect 55 items in March" and March historically runs 1.2x average, the forecast is 66. It's not magic. It's arithmetic with a bit of statistics on top. But it's far more reliable than the typical planning approach of "let's just assume next quarter looks like last quarter."

Two numbers tell you how much to trust your forecast: MAE and R². Let me make them concrete. If you typically receive 50 items per month and your MAE is 5, the model is off by about 10% on average. That's good enough for planning — you can work with a range of 45 to 55. If the MAE is 15, you're looking at 30% error, and the forecast is more of a suggestion than a prediction. Probably need more data or your arrival patterns are just chaotic. R² is about explanatory power. An R² of 0.85 means the model captures 85% of the variation in your data. The other 15% is noise, one-off events, random fluctuation. Generally, R² above 0.7 means you've got a useful model. Below 0.5, the model isn't finding a clear pattern — which might mean there isn't one, or you need more data points. When presenting forecasts to stakeholders — and you should present them, regularly — always frame them as ranges, not exact numbers. "We expect 45 to 55 items in March" builds trust because it's honest about uncertainty. "We expect exactly 50" sets you up for the inevitable "but you said 50 and we got 47" conversation. Add and subtract the MAE from your forecast to get a quick-and-dirty confidence interval. It's not statistically rigorous but it's practical and stakeholders appreciate the transparency.

A forecast isn't a one-and-done thing. Update it monthly with actual arrivals. Each new data point improves accuracy — the trend estimate gets sharper, the seasonal factors get more precise. After each update, check how the previous forecast performed against reality. Were you close? Consistently too high? Too low? These patterns tell you whether to adjust your model or your assumptions. Use seasonal factors strategically. If August has a factor of 0.7, that's 30% less demand than normal. That's your window for technical debt work, training, experimentation — the stuff that always gets deferred because "we're too busy." Conversely, if March is 1.3, make sure you're fully staffed and focused. Watch for structural breaks — moments when the historical pattern fundamentally changes. A new product launch, a market shift, a re-org that changes how work enters your backlog. When these happen, your old data stops being predictive. You might need to reset your baseline, starting the forecast from the break point rather than including pre-break history that no longer represents your current reality. One team I know does a monthly "forecast retro" — literally 10 minutes where they compare last month's prediction to actuals and note anything unusual. Over six months, they cut their MAE in half just by catching and correcting systematic biases in their estimates.