Estimating how long it will take to develop a software product is hard task. There are several approaches to be considered for effort estimation:
1. expert estimation: the figures are produced through a judgement process by experienced people
2. formal estimation methods: the figures are computed in an algorithmic way, usually based on historical data and on the parameters of the project to be estimated
3. a combination of the previous methods: some activities and tasks are estimated by experts, other using formal methods.
Historically speaking there are no studies that prove beyond doubt that one approach is better than the other or a method that is superior to others. Ideally each organization should choose the estimation method(s)that best fit the types of projects to be estimated.
I personally prefer expert estimation methods because are lightweight and additionally I tend to give credit to a person instead of an algorithm. On the other hand I don’t like "wild guessing", even if an expert is guessing. Considering this, my favourite estimation way of estimating is the following agile method:
1. decompose the project into phases, activities, tasks (i.e. work break down structure)
2. classify each task by complexity (e.g simple, medium, complex) and size (e.g. small, medium, large)
Note: there may be more complexity and size levels, but usually 5 is the upper limit.
3. define for each complexity-size category the estimated time for completion ( this should not be "wild guessing", but an estimation based on experience :) )
4. aggregate the estimations for tasks in a bottom-up manner to get the project estimation.
One thing to remember is to revisit and refine the estimates as the project progresses, assumptions are clarified, open points are closed and more information is available.
Subscribe to:
Post Comments (Atom)
I agree that estimation does generally work better if one has some experience with the subject matter. One thing to remember about estimation is that its main purpose is to provide predictability of schedule, so any method that reliably achieves that is probably a good one.
ReplyDeleteOne aspect that is not usually specified for an estimation is the degree of confidence/accuraccy. Because of this, many people tend to consider the actuals to be very close to the estimation (+/-10%) even if the estimation is done very early in the project. From my personal experience, the managers usually push technical people to make early project estimations and to commit to meet them. Afterwards they get angry when the estimates are changed while the project progresses because they have to rework their planning & financial figures.
ReplyDelete