Software Lifecycle has various stages like requirement gathering, implementation, testing and more. For a programmer lifecycle begins from “How long it will take?” and finishes at “It took longer than estimated”.
This is a dreary task, but a fact. There are a number of developers who are skilled and deliver the best, however, their work is never appreciated. If such cases are analyzed, it is found that the programmer is efficient, but fails to give 100% accuracy. Most of the time they provide very low estimates and are under high work pressure to meet the deadline that they either compromise with quality or miss the deadline. Any case they are at a loss. At the moment, you come across a lot of developers in this dynamic IT Industry who have a successful career, since they achieve the targeted deadline and have a good track record. Nevertheless, giving an appropriate estimation equally vital because training on how to code, how to learn new technology, how to surpass is imparted, but estimating is an expertise which is gained from years of experience.
Several companies across the globe do not make use of relevant effort estimation techniques or tools, that’s ghastly!
Various Effort Estimation Techniques:
Below are some most commonly used effort estimation techniques. Different techniques could be used considering the suitable use of the most efficient one.
1) Expert opinion: This is usually for startup with a team size is 10-50, where a single team member with high technical expertise of the industry is responsible for all technical decisions & estimation. The decisions and estimations are taken keeping in mind the team’s capability & technological acquaintance, identify risk factors at initial stage and guesstimate accordingly. Generally, a lot of MNC has subject matter expert (SME) who with their deep domain knowledge and experience to determine which technique should be implemented.
2) Work-Break Down Structure: Work-break down technique is a well tested and dependable estimation technique. Here business essentials are being factored in numerous technical task based on risk factors, unknown factors, control over technology, technical complexities. Every technical task estimation is provided on the ground of any of the above mentioned varied factors. One of the prerequisites of this technique is that you need a complete understanding of business requirements.
3) Estimation by Comparison: Estimation by Comparison is a technique which is depending on past experience of resembling specifications. Here estimations are formed by comparison, which is useful in providing necessary estimations though not accurate estimation. This techniques proves helpful to pre-sales persons especially who can give a ballpark estimation based on previous estimation given for similar requirements.
4) Three Point Estimation: Three Point Estimation is used to provide a more specific estimate, which is an average of the three estimations. In this estimation technique multiple estimation is developed and randomly 3 of them are selected. Finally an average estimation in produced out of these selected estimation.For example, let’s say for Project X we are using work break down technique which will be given to 3 different people and will be making an average of their estimation. This is a frequently used technique in IT sector.
- Keep a record of your personal estimates and actual effort.
- Include your unit testing time, final touch up time, buffer time in your effort – remember 80-20 rule?
- Note down all risk factors with their impacts as an attachment to every assumption.
- In any case pen down dependency as a third party API – it always takes more than your ever generous estimation.
- Do not estimate up to completion of task rather estimate for finishing the task, since in completion stage you achieve everything while in finishing stage it has to be user-friendly.
- Do not over estimate. Parkinson law proves that work expands automatically till there is time.
- Do not rely on only one estimation technique.
Please share your estimation tips & opinion in the comments.