Why velocity alone cannot predict a delivery date
Velocity gets treated as a forecasting tool far more often than its statistical properties actually support, and this module opens by explaining why: velocity is a rough capacity signal for a single team over a short horizon, not a probabilistic forecast, and using it to promise a specific date to a stakeholder is asking a blunt instrument to do precision work it was never built for. The alternative the module teaches is a small set of flow metrics, cycle time, work in progress, and throughput, that together support genuine probabilistic forecasting using each team's own historical variability rather than a single averaged number.
Lessons walk through reading a cycle time distribution honestly, including its long tail, since the item that took five times longer than the median is not an outlier to ignore, it is information about how the team's system actually behaves under certain conditions. A work-in-progress ordering exercise makes the connection between excessive WIP and worse cycle time concrete, since more in-flight work almost always means slower completion per item, not faster overall output, a counterintuitive result many teams have never seen demonstrated with their own numbers.
The module closes with Monte Carlo-style forecasting built from a team's own throughput history, giving a range of likely completion dates with explicit confidence levels instead of a single deceptively precise commitment date. A scenario puts the team in a familiar bind: leadership wants a single date, not a range, and the module gives language for presenting a range as more honest and, over time, more credible than a single number that keeps needing revision.
Mistakes teams make with this material
Treating a rough capacity signal as a precision forecasting tool, and committing to a date based on average velocity without accounting for the real variability in how long items actually take.
Reporting only a median or average cycle time, which hides the items that took far longer than typical and erases the information that describes why the system sometimes behaves unpredictably.
Starting more items simultaneously to look busier or more productive, when higher WIP nearly always increases cycle time per item and slows overall completion, a pattern the data reliably shows once measured.
Giving leadership one number under pressure to sound certain, instead of a probabilistic range built from historical throughput, which is both more honest and, over repeated use, more trustworthy.
Questions people ask
Why is velocity a poor tool for forecasting a specific delivery date?
Velocity is a rough capacity indicator that varies Sprint to Sprint and does not capture the underlying variability in how long individual items actually take. A probabilistic forecast built from cycle time and throughput history accounts for that variability directly, which a single velocity number cannot.
What is the practical effect of high work in progress on delivery speed?
It increases cycle time per item, almost always, because attention and context-switching cost gets spread across more concurrent items. Teams that reduce WIP typically see individual items finish faster even though fewer items are started at once.
How do you build a probabilistic forecast from a team's own data?
Use historical throughput, how many items the team actually completed per week or Sprint, over enough past periods, and run a Monte Carlo-style simulation to produce a distribution of likely completion dates rather than a single number, then report the date at whatever confidence level the stakeholder needs.
How do you respond when leadership demands a single date instead of a range?
Explain that a single date is a range with the uncertainty hidden rather than removed, and that a stated range with a confidence level, for example an eighty-five percent likely completion window, holds up better over time than a single number that keeps quietly slipping and needing revision.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Why does velocity fail as a cross-team performance metric?
- Because story points are always inflated
- Because each team's point scale is a private convention, so a point on one team means nothing on another
- Because velocity can only be measured monthly
- Because it requires a data team to calculate
Velocity is a valid internal capacity signal precisely because it is private and consistent within one team; comparing it across teams compares unrelated scales.