Life is not Black and White, so are estimation techniques. This is just one of the simple heuristics of life which works most of the time but not all the time.
This is again a very common question that comes up during my discussion with my BA colleagues. There are so many estimation techniques. BABoK® itself mentions 8 different techniques, I trust if we search other literature, it will happily be 15+. Is there a flow chart that we can build to quickly choose the appropriate estimation technique?
Estimation techniques are helpful to understand possible range of costs and efforts associated with any change. Let’s have a quick overview of all 8 estimation techniques mentioned in BABoK®. They are:
- Top-down estimation
- Rough order of magnitude (RoM) / Ballpark / Expert opinion
- Delphi estimation
- PERT (Program Evaluation Review Technique)
- Bottom-up estimation
- Parametric estimation
- Rolling wave
Estimate efforts for components using hierarchical breakdown. Typically done when the budget is fixed.
Uses WBS to estimate deliverables, activities, tasks, and estimates from all involved stakeholders and rolls them up to get a total for all activities and tasks. It is easier to estimate smaller items than larger items. This can produce accurate and defensible estimates.
Uses a calibrated parametric model of element attributes. For example, if one use case takes 3 days, 20 use cases will take 60 days.
Rough order of magnitude (RoM) / Ballpark / Expert opinion
Based on limited information, a high-level estimate with a very wide confidence interval. Typically based on history or expert judgment.
Involves continual refinement of estimates. Estimate details for activities in current iteration and extrapolate it for the entire scope of work. As the end of iteration approaches, estimates for next iterations can be updated.
Uses a combination of expert judgment and history. Include individual estimates, sharing estimates with experts and having several rounds until a consensus is reached.
PERT (Program Evaluation Review Technique)
Each component of estimate has 3 values:
- (M) Most likely estimate (3 days)
- (O) Optimistic or best-case scenario (2 days)
- (P) Pessimistic or worst-case scenario (7 days)
PERT estimate = (1 * Optimistic + 1 * Pessimistic + 4 * Most likely)/6 = (4*3+2+7)/6 = 3.5 days
Now that we have a basic understanding of the techniques, I am proposing the following flowchart to choose the most appropriate estimation technique.
When the budget for a change is fixed, we must use top-down estimation. All sub-component estimates together must be equal or lesser than budget available. This method is quite common in agile / scrum based projects for the sprints.
Now let’s start with a new project where there is very little information available to us at this point in time. We even do not have a detailed scope and only a broad description is available for the project. In this situation, the most appropriate technique that we can use is to consult an expert who can give us an idea about the likely estimate for the project or deliverable. This is what BABoK® calls as Expert Opinion or Rough order of magnitude technique. Obviously, the range of variability associated at this level would be quite high, even in the range of plus or minus 50%.
Is it ok to trust a single expert to estimate a complex task or project? Possibly not. If there is a lot of things at stake, it’s always better to consult multiple experts to arrive at an estimate. This is where Delphi comes into play where multiple experts estimate the project or task in hand independently in the beginning. Then they reconcile their estimates.
If all of them happen to have very similar numbers, then we can trust that estimate. But if the numbers are quite different, then they have to discuss and figure out what is the assumption that they’re making and why their estimates are not converging. With discussions, they may be able to convert at an estimate which is what would be used for the project. Planning poker is a classic example of Delphi being applied in an agile scenario.
Many organizations repeat similar work and they capture effort details about the tasks. If the organization has sufficient historical data, it may be possible to use that historical data to estimate the work in hand. For example, if historical data indicates that the organization has been taking about 3 days to develop one use case and the project involves writing 20 use cases, one can safely say this project is going to take about 60 days of business analysis effort.
In case we are interested in conducting a scenario analysis and factoring in pessimistic and optimistic scenarios, we can use PERT method. In PERT method, we give four parts weight to the expected estimate, 1 part to optimistic and pessimistic each. This is divided by 6 to get PERT estimate. Heuristically, one can close to get PERT estimate by adding 10% to estimated bottom-up estimate as well.
As the project scope gets defined, even if we do not have past data, we still can estimate at the component level and combine the component estimates to come up project estimate. This is what is called as the bottom-up estimate. Bottom-up estimates can be pretty accurate as long as we make sure that we haven’t left any elements in our decomposed structure.
I have created a template which has all worked out an example for all these estimation techniques for a particular case. If you are interested in obtaining the template, please like/comment on the blog. The Adaptive team would share that template with you.
I am a practicing business analyst, trainer, author and blogger.
I have helped more than 400 business analysts to achieve their dream careers by getting them certified in international BA certifications.
I have authored 10+ books on business analysis and 200+ blogs.
I am a certified business analyst from IIBA® Canada and IREB® Germany.