Macadamian Blog

4 Ways To Review An Estimate With Limited Time And Limited Expertise

At last week's OSEF meeting, a scenario was described: you've planned a technically complex feature in your next release, and your senior developer has researched it and put out an estimate of 6 weeks to complete. Of course you trust your developers, but anyone can make a mistake. Without knowing anything about about the technical aspect of the new feature, and with limited time to review, how can you verify if the estimate is at all accurate?

1. Review The Work Breakdown

The most accurate type of estimate is a bottom-up estimate, so hopefully your developer broke down the feature into a list of tasks and sub-tasks. And the finer the granularity, the better. Are there any tasks that seem too high-level, like "Develop the UI" at 15 days, or "Multi-Thread Mechanism" at 10 days? At Macadamian, any sub-task estimated at 4 days or more is considered suspicious and should be cause for a bit of Q&A. What is really going to happen within that 15 day task? Couldn't it be broken down further into smaller sub-tasks? Without even understanding the technology, a granular breakdown of sub-tasks is already a good sign of a well-thought estimate.


2. Review The Top 3 Risks

Ask the estimator to list the top 3 risks of the feature. Often, we think only of the success path when estimating, overlooking everything that might go wrong. When it comes time to implement, the risks rear their ugly heads and the success path, and the accuracy of your estimate, is ancient history.

Have a look at the 3 risks. Are they clear and detailed? Are they really the top 3 risks, or can you think of other bigger risks? What is the probability of occurrence? What is the impact if they do occur?

What are the proposed mitigation strategies? Are they taken into account in the task breakdown?

3. Review The Non-Technical Tasks

When focusing on a complex technical feature, it is easy to forget about the "obvious" non-technical tasks - management tasks, coordination, unit testing, bug fixing, answering questions, integrating with other features, documentation, contacting 3rd party vendors, etc.

Is setup of a nightly build part of the estimate? What about the integration of tools like NUnit and FXCop? How about meetings that can add up to several hours per week? Time to integrate 3rd party vendor fixes? Time to merge the branched code into the main branch of source control?

They may be small in comparison to implementing a complex thread dispatcher, scheduling algorithm or power management scheme, but when you add up all these little half tasks, they can actually account for a significant chunk of the estimate.

4. Hold A Brainstorming Session

Although I typically recommend a single peer to review code as opposed to a whole group, when it comes to estimates I believe the more the merrier. Different people have different background, different roles within the company, different concerns, etc. Holding just 1 brainstorming meeting when an estimate is first drafted can bring up all kinds of new issues that no one ever thought of. In fact, I would say that including more of the team in the estimate review is the 1 major factor that has improved our estimation accuracy.


Of course, there are all kinds of processes and software out there that can improve your estimation accuracy: function points, Delphi technique, risk estimation calculators, Monte Carlo simulation, etc. As a product outsourcing company, accurate estimates are crucial to our business, and we're always looking for ways to tighten them up further. But additional processes can take big time and cost big money - not something that you can always justify for the work at hand.

The above tips are designed to give you the most benefit in a short amount of time. In fact, you could probably apply all 4 tips in 1 day, so you can get started on the actual development ASAP.