5 Laws of Software Estimates – Explored, Explained and Debunked
1. Estimates are fixed
Software estimates are not always exact and fixed, mainly because of the fact that team members are different personas. By estimating one team member, you can not predict how long it might take another team member to complete a task.
This is a crucial point of the estimation (forecasting) theory. You should record the estimates at the moment they are made, classify the estimates by the categories of project, put estimates in a spreadsheet and use then again when you will face a similar type of project. This is standard software engineering approach in many IT organizations.
2. Estimates are a waste of time
The time you will spend on estimates will not bring you any value. Sometimes the estimates are being requested urgently, thus interrupting the developers who would otherwise work on really productive tasks. Asking for an estimate will waste their time trying to get work done. If you ask your software developers to spend 2-4 hours per week on estimates, that’s around 7% loss in productivity, if they are really able to be productive the entire time. The situation is worse if the developers are engaged on a part-time basis, or are only able to code software in parts of their working week. The estimates should not be allocated to the developers; they’re for the developers’ managers.
Estimates can assist software developers to plan their work schedule, needed staff, and other resources, but in some cases, it will take them away from their development duties. Writing commercial software requires money as a resource, sales revenue to be acquired to cover the cost. This should be a CEO’s issue, not a coder’s point of view.
3. Estimates are inaccurate
Estimates are not assurance; they are guesses, and generally – the larger the scope and the further in the future the activity being estimated is, the greater the possible error is. This is one important aspect that ignores the mathematics of estimating.
An estimate can be a guess, but that is a bad approach for estimating. You should avoid naive steps on purpose. You should read good estimating software practices, and learn how to estimate, so you won’t be saying naive things like estimates are guesses.
4. Estimate are important
Despite the previously mentioned facts, estimates are sometimes necessary. Companies cannot make decisions whether they should start a software project, without having some idea about the cost and time required. Making decisions in the presence of uncertainty will involve estimates of the outcomes and impacts of those decisions on future.
So if you need to apply any of the above ideas, you should ask yourself what will be the value at risk for not estimating the impact of your decision.
5. Estimates are short-lived
Estimates are really unstable. They can be changed in short term period. The developer could initially estimate that a certain item will take a week to develop before the project has started. But when into the project, a lot of issues appeared and get resolved, and that same item might now take a few hours or a month, or it might have been dropped from the project completely, due to changes in priorities or direction. In any case, the estimate will have little or perhaps (even) negative value since many aspects have potentially changed since it was created.
As you see, estimates are short-lived and they are updated periodically with new information. This is a standard estimating process.
