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
Document: CHAOS Report 2015 (PDF, copy hosted by Info-Tech Research Group), read 8 October 2026.
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.
Related references on this site
Frequently Asked Questions
What is the success rate of agile vs waterfall?
In the Standish Group CHAOS Report 2015, which scored more than 10,000 software projects over FY2011-2015 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. So agile projects succeeded at roughly 3.5 times the rate of waterfall, and waterfall projects failed at more than three times the agile rate.
Does the agile advantage hold for large projects?
Yes, and it widens. In CHAOS 2015 the agile-versus-waterfall success gap is largest on the biggest projects: on large projects 18% of agile projects succeeded against just 3% of waterfall projects (a six-fold difference), while on small projects the gap narrows to 58% agile versus 44% waterfall. The Standish reading is that waterfall does not scale, while agile holds up better as size grows.
Why are these success rates lower than other agile studies quote?
Because CHAOS 2015 uses the strict Modern Resolution definition: a project counts as successful only if it was on time, on budget, and delivered a satisfactory result. That is a much higher bar than 'the project shipped'. Reports that use the older OnTime/OnBudget/OnTarget metric, or that count any delivered project as a success, produce higher percentages. When comparing agile and waterfall figures, always check which definition of success is being used.
Does agile cause the higher success rate, or just correlate with it?
The CHAOS data is observational, so it shows a strong association, not proof of cause. Agile projects tend to be smaller and to break work into shorter increments, and small size is itself the strongest predictor of success in the CHAOS data. Standish argues the two reinforce each other: agile encourages smaller batches, and smaller batches succeed more often. Treat the figures as evidence of direction (agile and small-batch delivery outperform large waterfall projects) rather than a controlled experiment.