How much effort should we spend improving?
Agile is all about iterative development, continuously adding value and continuously improving our product and our process. In all too many companies Agile is adopted without really investing in continuously getting better. The business may get the benefits of incrementally adding value, of greater predictability, but does quality rise? Does the team throughput increase? We would like to imagine that a team can continue forever delivering the same amount every sprint — but that's rarely what happens.
How to read this
The chart above shows two views of the same simulated team: velocity per sprint on the left and cumulative work delivered on the right. Red is a team that doesn't invest in process improvement; blue is a team that does.
Three inputs control the simulation:
- Entropy — the % a team slows down each sprint because of accumulating retest, rebuild, and maintenance work.
- Improvement cost — the % of capacity the team reserves for improving the process rather than adding features.
- Improvement gain — the % velocity recovered per sprint by that investment.
Five scenarios worth trying
1. The team that doesn't improve. Set entropy = 3, improvement cost = 0, gain = 0. Even at just 3% entropy, velocity halves over a year and cumulative output drops by more than 25%. This is the default trajectory for many real teams.
2. A small steady investment. Set improvement cost = 20, gain = 3. The improving team starts behind (only 80 in sprint 1) but crosses ahead on velocity around sprint 8 and on cumulative work around sprint 17.
3. A weaker improvement. Drop gain to 2. The improving team still pulls ahead within twelve sprints — even modestly effective process work pays back inside a year.
4. A stronger improvement. Set gain = 4. The improving team doubles its sprint velocity in a year and delivers more total work after only twelve sprints.
5. A more expensive improvement. Set cost = 30, gain = 3. The improving team starts even further behind (70 in sprint 1) but payback still happens inside one year.
What this tells us
The numbers are illustrative — there's no rule that says 20% effort delivers exactly 3% gain. But the human brain is poor at estimating the impact of compounding changes, and experience backs up the data: teams that consistently spend whatever's required to maintain velocity significantly outperform teams that focus only on short-term goals and immediate value.
In SCRUM, arguably the most important ceremony is the once-a-sprint retrospective. It exists for exactly this purpose: identify one or two experiments that should improve the team's biggest current bottleneck. The question this page is trying to help answer is — how much of the team's capacity should that work consume?
Prefer a spreadsheet?
Download BenefitOfIterativeImprovement.xlsx to explore the same model with full control over the underlying numbers.