Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula

Effort estimation in software development is complex. Traditional estimation techniques such as COCOMO and Functional Points are fine for traditional development approaches but they are not appropriate for agile approaches where you don't know the entire lifecycle time span in advance and the entire estimation process may seem a bit too overwhelming to the agile, more fluid approaches.

Once user stories have been prioritised, developers are then able to estimate the duration, in development effort, to complete the stories. The total effort is calculated and finally, the iteration will contain only the most valuable stories, the ones that deliver the most value to customers, in a fixed timeframe (the iteration).

The challenge is to accurately estimate the effort to complete the user stories on time. One may ask if the estimation needs to be so accurate for the agile methodology because if one user story does not make an iteration, it can always be accommodated into the next iteration. The risk with this approach is that important functionality may not get delivered because of delays in previous iterations and when deployment comes along there is a backlog of stories that did not make the build. This may be fine for the agile practioner (when thinking that you are delivering value and not delaying the project), but it probably is not fine for the customer and, depending upon contractual agreements, you may be penalised in various different ways for not delivering the promised functionality.

Before I proceed let me just take a pause and mention that in the case of the scenario mentioned in the previous paragraph, the agile practioner should continue to focus on releasing the software on time and on delivering value. If delays start to occur and functionality is consistently pushed back to other iterations, the project manager should immediately start communicating with customers to either reprioritise stories or to develop a plan to ensure that value is delivered to customers in a consultative and mutually agreed manner.

No one has the final answer on how to accurately estimate task duration. Various techniques have been developed to address the issue. I have been effectively utilising the PERT estimation technique detailed below.

The PERT estimation techniques uses a system of categorising 3 potential estimations as Realistic, Pessimistic and Optimistic.

A number is assigned to each of these variables which are then applied to a formula to devise the final estimation. The values applied to the formula can either be in hours or days, depending upon the size and complexity of the project. Needless to say that whatever unit of measure applied, it needs to be consistent for the entire iteration.

The formula is as follows: (Optimistic + (4 * Realistic) + Pessimistic) / 6.

I ask developers to provide me with estimation for the tasks in question. I take the numbers provided by the developers and apply them to the Optimistic component of the formula. I am pretty sure that many people will criticize me for implying that developers always provide estimations that are optimistic. There are many articles on the internet that support the fact that developers are the only ones that know exactly how long will take to complete a task. I don't entirely disagree with them. Feel free to change this aspect of the technique to address you environment, you may have developers that consistently provide estimates that are realistic, if so adjust the technique accordingly.

My motivation in applying the developer's estimation to the optimistic component of the formula comes from motivational management theories, unconscious motivation to be specific, and experience. Some motivational theories support the fact that workers will always try to do the best that they can, in this case, they may try to be as efficient as possible and provide you with estimations that are not achievable.

The next step in the process is assigning values to the realistic and pessimistic components of the formula. To figure out these components I have a system whereby I assign a grade to a task in order to estimate potential duration. The grade is based on size and complexity. The following tables provide more details with regards to how to choose these grades.

Following from these tables you can build a matrix with possible combinations and estimations to use to complete the realistic and pessimistic components of the formula. I have not posted my table because, in building it, you have to consider several different variables to devise those numbers. Some variables to consider include technical prowess of your team, number of developers available, iteration length and others.

Once you have the table built you can continually update it as you find variances between estimated and actual completed time.

This may sound a bit too hard for an agile approach, nevertheless as you get used to it, it is actually very easy and, over time, it speed us the process of task estimation and, more importantly, makes it more accurate.