Engineering teams are notoriously bad at predicting delivery dates — not because engineers are poor estimators, but because the systems they work in weren't built for accurate forecasting.
Requirements change. Dependencies get blocked. PRs take longer to review than expected. The new engineer onboards slower than planned. These aren't failures — they're normal. The question is whether your process anticipates them.
Delivery forecasting does exactly that.
What is delivery forecasting?
Delivery forecasting is the process of predicting — with increasing accuracy over time — when work will be completed. Unlike deadlines (which are fixed commitments), forecasts are probabilistic estimates that update as new information arrives.
Good forecasting answers:
- When will this feature ship, given current velocity and remaining work?
- What's the risk this sprint's goals won't be met?
- Which dependencies are most likely to cause slippage?
The 4 inputs that drive accurate forecasts
1. Historical velocity
The single most valuable input. How much did your team actually complete vs. what they planned, averaged over the last 4–6 sprints?
Teams consistently underestimate by 20–30%. Once you know your actual ratio, you can correct for it in all future estimates.
2. Scope clarity
Vague tickets take longer to implement and longer to review. Rate the clarity of each piece of remaining work:
- High clarity: requirements are locked, designs approved, acceptance criteria defined
- Medium clarity: requirements roughly known, some ambiguity remains
- Low clarity: "we know we need this, but not exactly what it is"
Apply multipliers accordingly: 1x, 1.4x, 2x.
3. Team capacity
Available hours minus meetings, leave, onboarding, and planned review cycles. See the capacity planning guide for the full framework.
4. Dependencies
Every external dependency is a risk multiplier. API from another team. Third-party integration. Design sign-off from stakeholders. Map them explicitly and flag the ones with no clear ETA.
A simple forecasting model
With these inputs, here's a lightweight model:
Remaining effort = Σ(task estimates × clarity multiplier)
Adjusted velocity = Historical velocity × team capacity ratio
Forecast completion = Today + (Remaining effort ÷ Adjusted velocity)
This is rough — but it's dramatically better than "we'll get it done by end of month" with no backing.
When to raise a forecast alert
Flag delivery risk when:
- Forecast completion date is > 2 days past the committed deadline
- Team velocity this sprint is tracking > 20% below average
- A high-criticality dependency has no ETA after 5 business days
- Scope has grown > 15% since the sprint started
How TaskSpread automates forecasting
TaskSpread tracks your team's velocity automatically and surfaces delivery risk alerts when:
- Current sprint is tracking below historical baseline
- A task dependency is overdue
- Estimated completion date has drifted past the committed deadline
No manual calculations. No custom dashboards to build. See delivery forecasting in action.