If you cannot do your budgeting at home maybe you should not be assessing software build
Out of curiosity, how many of you are disciplined enough to have an accurate house budget and how many overspend and live on credit cards?
If you belong to the last category, how do you make proper estimations when it comes to software when you cannot properly estimate you budget at home accurately? If you think the two are not connected and even more, that if there is a connection is a very weak one, think again.
Picture this: if the task you know best and have most control over cannot be correctly estimated, how do you know to estimate accurately work related tasks given by someone else? I am tacking the behaviour and not the specifics of each household and their expenses.
Most of us are in this situation and I know very few people that do not overspend and nothing bad happens to them — it is more so encouraged by today’s society. Now, don’t get me wrong, this is a sin I am sometimes guilty of as well.
What I really think: the only thing that can be accurately estimated is something that has been done before several times or something that is mathematical — there is no way to accurately estimate tasks that are new to you and even more — the breakdown of tasks into smaller ones that can be more accurately estimated is viable until one point. Even with those done, there is an obvious discrepancy between estimated and completed.
Bottom line: the more tasks to estimate, the bigger the difference. This is also supported by literature:
“The book The Mythical Man Month was published in 1975 and in Chapter 8, it covers the topic on estimating. Based on research in the 60s and 70s, and gathering insights from industry professionals, the book comes to a similar conclusion:
How delivering software usually takes twice as long as most engineers estimate*. And how engineers are overly optimistic and when asked what were things that caused delays, they mention machine failures, higher priority unrelated jobs, meetings, paperwork, company business, sickness, personal time etc came up.”
As the linked article mentions, this is 50 years ago when business and tech had a very different relation and things were waterfall-ish. Meaning that the business requirements did not alter every week and attrition rate companies faced was way smaller.
Today, I know the gap to be bigger. Let me tell you why (and remember this is not planning of incompetence — it’s just life!):
- in most business situations, requirements evolve from sprint to sprint and things may change even faster than that;
- interlocutors change from sprint to sprint (for eg. when developing a platform for multiple areas and customers you encounter situations where you need to constantly factor in region-specific requirements);
- some of the requirements are not described or known from the begging.
I used to say 1.8 times more when it comes to estimations based on the above list however I reached the conclusion there is no real estimation as the base definition of a story point (it may be T-shirt size if you may) is filtered and understood differently by all developers.
This estimation thing is somehow a soft concept that many seem to have troubles grasping as it is not black and white and more like a bundle of greys and I do not blame them. Sometimes I have the feeling I totally get it and when I try to look at everything from above and zoom out it just stops making sense and looks all scrambled.
Coming back to the point at hand — now, when dealing with estimations, add a significant margin to your numbers. This is not to look incompetent but rather to look competent.
Since I am not the only one that thinks that, check this post below from Gergely Orosz: https://www.linkedin.com/feed/update/urn:li:activity:6926240566233997312/
Originally published at https://www.linkedin.com.