Agile Scrum Estimations Fail

The whole driver behind Agile was that we can’t estimate very well. Sure, we can make vague claims like ‘adding a connection pool will take half a day’.

But we cannot account for the fact that somebody else already added a conflicting one in a module we’ve never heard of. The library we plan to use has a bug in it that is only triggered by our specific usage. The precise handling of timeouts breaks our circuit breaker behavior two services up and none of us yet know there even was a circuit breaker there.

Software development is full of uncertainty. It has a multiplier:

uncertainty actual uncertainty of core problem
X team unfamiliarity
X size of the team
X number of stakeholders
X quantity of new team members
X lines of code
X amount of unclean code
X amount of duplication
X network and connection issues
X outstanding technical debt
X number of separate teams
X inexperience of BA and PM
X distance of new requirements from old ones

This all gets washed away by the pretense that story point estimation and a velocity chart “makes that all go away”.

It doesn’t.

As the amount of existing work increases, the number of unknown ‘gotchas’ increases team-wide.

I have yet to see a formal, accurate forecasting method for software delivery schedules that a PM would actually bind themselves to.