When you are working on a software development project you need to estimate the required effort for tasks or a whole project. In traditional project management (waterfall) it is necessary to estimate the overall expenses for the project before it has even started. This comes along with high uncertainties and risk. In projects that are using agile approaches the uncertainties are lower, because you only need to consider the next iteration in detail (in case of Scrum). Nevertheless it is necessary to estimate effort and there are different approaches for that.
The definition of estimation (Wikipedia): “Estimation is the process of finding an approximation which is a value that is usable for some purpose […] . The value is nonetheless usable because it is derived from the best information available.”
A guesstimation is an estimate that is made without using adequate or complete information, or, more strongly, is an estimate arrived by guesswork or conjecture. Therefore the uncertainties of a guesstimation are higher than in estimations. The important fact is that an estimation is an approximation and not a sound value.
Why Estimate the Effort
Estimating the effort for a project, or parts of a project, is necessary, because it is necessary to plan the work. There is always someone who wants to know when the project will be finished or how much work is still left. This could be the product owner, the client, the project manager or a fellow programmer who needs the result of your work.
The accuracy of an estimation depends on multiple factors like the size of the task/package, the number of involved systems, the skills and knowledge of the programmer, how well the topic is known, … Hence there are lots of uncertainties that result in a fluent boundary between estimation and guesstimation. The problem is that the person who asks for the estimate expects it to be correct.
As mentioned above there are a lot of factors that influence the accuracy of estimates. Aside from the uncertainty of requirements or technologies and the skills of the programmers there are also psychological issues that need to be considered. Knowing that they exist may help you to improve your estimates.
Influence by other estimations and values:
As soon as the person who estimates has heard a number, e.g. by the client, this number is in his head. From that point on each estimated value will be evaluated against the other number. The result is that the estimate will be quite close to the other value.
The remedy: The estimator should not know about any other numbers until he is done with his estimate.
Wording that implies high or low:
If there are words that imply high or low in the description of the task/package/project that the estimate is about, the person who estimates is influenced by them. Those words could be huge, big, difficult, extensive, easy, little, short, …
The remedy: Someone unrelated to the estimate goes through the description and eliminates those words, if possible.
Possible future opportunities:
The knowledge about possible future opportunities lowers the estimated value. The reason for that is that the estimator tries to improve the probability of the additional project by a cheaper first project.
The remedy: The estimator should not be involved into the acquisition of new projects.
If there is irrelevant information in the description of the task/project, the estimate normally is higher, because the topic seems to be more complex.
The remedy: Someone who is not involved in the estimation should try to eliminate irrelevant information before the estimation begins. The problem is to decide whether or not an information is irrelevant.
In general there are two different approaches to estimate effort: expert estimations and formal estimation models.
The expert estimation approach is based on one or more experts that are following a judgmental process which means that people thinking about the task and estimate or guess how long it would take them to complete it. If you follow this approach it is important to have the psychological issues in mind to minimize their impact. In contrast to the judgmental processes of the expert estimation the formal approach quantifies the effort based on mechanical processes, e.g. formulas that are derived from historical data. The usage of formulas or other mechanical processes reduces the impact of the psychological issues, because the process is based on facts. Techniques for expert estimation are for example Planning Poker or Magic Estimation. Formal estimation approaches are Function Point Analysis or COCOMO.
Of course it is possible to combine the two approaches to achieve the best possible result. For example the formal estimation is difficult if there is no data available about the topic that effort needs to be estimated for. On the other hand the immunity against the psychological issues of the formal approach can be a big advantage. The expert estimation has the advantage that it is flexible and it can be applied to all topics and types of projects.
No matter which estimation approach you are adopting you can use concepts that help improving the accuracy of the estimation. These are:
- Mapping of features from older projects to those in new projects.
- Converting complex stuff to simple stuff.
- Taking risks into account.
- Comparing your estimates with the really used effort in retrospect.
How We Do It
We for example use the expert estimation approach inspired by Planning Poker:
- Depending on the size of the project we are selecting a team (often 3 or 4 people) that conducts the estimation. At best all team members will also be part of the implementation team.
- Firstly the team breaks down the topic into tasks that are manageable. At that time they are not allowed to talk about possible estimates, possible problems or difficulties. It’s purely about the technical facts.
- After that each team member estimates the effort for each task in man-days. Still they are not allowed to talk to others about their estimation. During the estimation process they identify uncertainties.
- When the team meets again it compares the estimated efforts for each task.
- If the estimations of the team members are closely together they agree on one value.
- If they are wide apart they have to discuss the task in more detail. After this discussion they agree on a value. If they can’t agree the task will be investigated in more detail afterwards.
- When the team has agreed on values for all tasks the overall effort gets calculated.
- In retrospect the team compares the estimated effort for the tasks with the truly used time.
The effort of conducting the estimation like this is quite high, because it involves several people, but for us this approach works just fine. The combination of independent estimates and discussion of controversial tasks helps us to give good estimate. The crucial point is that the team members don’t get any hints on the estimations of the others. The good thing about the team is that it is more likely that a team takes all aspects of tasks into account, because the team members have a different background and experiences.
Since it is always necessary to estimate the effort for some tasks it is important to come as close as possible to the real effort. No matter which approach and concepts you are using, the most important factor is the experience of the estimator. Therefore you should never avoid estimations, even if it feels bad in the beginning because you are far away from the real effort. Over time your estimates will get more and more accurate. Knowing the different approaches, concepts and psychological issues helps you to become better faster.
If you don’t really believe in guessing and estimating efforts you should take a look at the no estimates movement. This approach follows the idea that it’s not necessary to estimate the effort for tasks or projects, because it focuses on lean principles like limiting the work in progress. It’s an alternative approach that maybe suites you and your projects better than spending a lot of time in estimating efforts (which often is necessary due to the project or to the contractual situation).
With kind regards,
your SCM-Manager Universe Team