Critical Path Newsletter

Reviewing an estimate with limited time and expertise

Your senior developer comes into your office with that estimate for the highly technical and complex feature that would be great to have in the next release. He’s estimated six weeks. There are six weeks and one day left in the cycle. You need to make sure the estimate is accurate, but you’ve never touched that technology before.

Where do you even start? Is it possible to review an estimate when someone else is the expert in the area and you're not?

At Macadamian, because we’re a software development partner company, our bottom line depends on accurate estimates. An estimate that’s too high might mean the price is too high for the client. An estimate that’s too low means that we'll let the customer down on the deliverables. And the more time we spend reviewing estimates, the less time we have to do the project.

So, with estimates being so crucial to our business, here’s what I do when faced with an estimate that’s beyond my experience.

• Review the work breakdown
• Review the top three risks
• Review the non-technical tasks
• Hold a brainstorming session

Review the work breakdown

When it comes to estimates, bottom up is better. At Macadamian, every feature is broken down into a list of tasks and sub-tasks—the finer the granularity, the better.

Look at the estimate. Are there tasks that seem too opaque, like Develop the UI for fifteen days, or Do the multi-thread mechanism for ten days?

A granular breakdown of sub-tasks is a good sign of a well-thought-out estimate. Any sub-task estimated at more than three days should raise a flag and can usually be broken into smaller sub-tasks. What is going to happen within that fifteen day task? Just off the top of my head, couldn’t it be subdivided by screens?

Review the top three risks

Ask the estimator to list the top three risks of the feature. It’s tempting to think only of the success path when estimating, overlooking things that might go wrong. Then, when it comes time to implement, risks rear their ugly heads, making the success path—and the accuracy of your estimate—ancient history.

Analyze the top three risks that are identified. Are they clear and detailed? Are they really the top three, 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?

Review the non-technical tasks

When focusing on a complex technical feature, don’t forget the "obvious" non-technical tasks—management, coordination, unit testing, bug fixing, answering questions, integrating with other features, documentation, contacting third party vendors, etc.

Is setting up 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 third party vendor fixes? Merging branched code into the main source control?

In comparison to implementing a complex thread dispatcher, scheduling algorithm or power management scheme, these tasks look small. But when you add them all up, the little tasks can actually account for a significant chunk of the estimate.

Hold a brainstorming session

When it comes to code review, I recommend a single peer do it, rather than a group review. When it comes to estimates, I take the opposite view. The more, the merrier.

Different people have different backgrounds, different roles within the company, and different concerns. Holding a brainstorming meeting when an estimate is first drafted can bring up new issues the estimator hasn’t thought of. In fact, I would say that including more of the team in the estimate review is the Number One factor that has improved our estimation accuracy at Macadamian.

Other techniques

There are all kinds of processes and software out there that can improve your estimation accuracy: function points, the Delphi technique, risk estimation calculators, Monte Carlo simulations, 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 you can always justify for the work at hand.
These tips are designed to give you the most benefit in a short amount of time. In fact, you could probably apply all four techniques in a day, to let you get started on development ASAP.