Agile vs Waterfall Success Rate
The most-cited head-to-head on delivery method comes from the Standish CHAOS Report 2015. Here are the exact success, challenged, and failed percentages, by project size, read from the primary report.
What is the success rate of agile vs waterfall?
In the Standish CHAOS Report 2015, across more than 10,000 software projects (FY2011–2015, scored on the Modern Resolution definition: on time, on budget, with a satisfactory result), 39% of agile projects were successful against 11% of waterfall projects. Agile projects failed 9% of the time versus 29% for waterfall. In short, agile projects succeeded at roughly three and a half times the rate of waterfall, and the gap is widest on the largest projects.
The full resolution table, by project size
The headline 39% versus 11% is the all-sizes figure. The more useful story is what happens as projects get bigger: waterfall barely scales, while agile degrades far more gracefully. On large projects agile succeeds at six times the waterfall rate (18% versus 3%).
| Project size | Method | Successful | Challenged | Failed |
|---|---|---|---|---|
| All sizes | Agile | 39% | 52% | 9% |
| Waterfall | 11% | 60% | 29% | |
| Large | Agile | 18% | 59% | 23% |
| Waterfall | 3% | 55% | 42% | |
| Medium | Agile | 27% | 62% | 11% |
| Waterfall | 7% | 68% | 25% | |
| Small | Agile | 58% | 38% | 4% |
| Waterfall | 44% | 45% | 11% |
CHAOS RESOLUTION BY AGILE VERSUS WATERFALL, Standish Group CHAOS Report 2015, page 7. "Successful" uses the Modern Resolution definition (OnTime, OnBudget, with a satisfactory result), not the older OnTime/OnBudget/OnTarget metric, so the percentages are lower than reports using the traditional definition. Each row sums to 100%. Figures read directly from the primary report.
What the numbers actually say (and do not)
The CHAOS agile-versus-waterfall table is one of the most-quoted statistics in software delivery, and it is also one of the most misused. Three things are worth keeping straight:
- The definition is strict. A project only counts as successful if it landed on time, on budget, and with a satisfactory result. Under a looser "did it ship" test, both columns would be far higher. The gap between agile and waterfall is the interesting part, not the absolute level.
- Size and method are entangled. Agile projects tend to be smaller and delivered in shorter increments, and small size is independently the strongest predictor of success in the CHAOS data. The report does not fully separate "agile helped" from "agile projects were smaller". Read the table as evidence of direction, not a controlled trial.
- It is a survey, not an audit. Standish collects self-reported outcomes from IT executives and does not publish the raw sample. Academics (notably Eveleens and Verhoef, 2010) have argued the definitions inflate failure rates. The direction, that agile and small-batch delivery outperform large waterfall efforts, is robust across the data; the exact percentages should carry that methodological caveat.
For the budgeting implication, the lesson is the same one the whole CHAOS dataset points to: break large programmes into small, independently deliverable pieces, because size is the variable most under your control.
How to cite
Authoritative source: standishgroup.com
The full CHAOS reports are paywalled; the 2015 agile-versus-waterfall table is widely reproduced in openly accessible secondary sources (Scrum.org, InfoQ, PM World Journal) and matches the figures above.