Let’s be honest: software estimation is less like engineering and more like astrology with Jira tickets. You’re peering into the future, tweaking something about “pace” and “story points,” and hoping for the stars (and stakeholders). Everyone knows full well that “two weeks” means “whenever the universe allows.”
So why is it so difficult?
Because software isn’t like building bridges – it’s like Halfway through it is Inventing a New Kind of Bridge, in which three interns swap blueprints for memes. You’re dealing with unknowns: requirements that change faster than a toddler’s favorite color, libraries that become obsolete overnight, and a colleague who swears by it. llvm/clang Makes “just for fun”.
Traditional estimates attempt to predict human creativity in spreadsheet form. It’s cute. One can’t create a Gantt chart model “debugging a race condition that only happens on the boss’s laptop during a full moon.”
Basics of Live Estimation
- Estimate in limits, not absolutes. “It will take 3-5 days” sounds confident and mysterious. “It will take 4 days” sounds like a lie waiting to happen.
- Multiply by π. Engineers joke about doubling time and adding one. I prefer multiplying by 3.14159 – it sounds more scientific, and who’s to argue…