Project Estimation Best Practices: A Look at Our Three-Point Estimator

One of the biggest risks in undertaking a big software development project is underestimating the time and effort involved from start to finish. Our team has provided estimates for hundreds of projects, and sometimes we’ve missed the mark, especially in the early days of our business.

Over the years, we’ve put together a strong model for estimating how much time and effort a project is likely to require; our employees undergo annual training on the method. Using these methods ensures we present our clients with the most useful estimates possible and effectively set expectations for each project.

Not Just Simple Math

When you think of hours estimation, you probably imagine a small team of people putting together a list of tasks and then assigning hours to each. From there, it’s just simple addition, right?

From the outside, I’m sure that’s what the estimation process seems like. Behind the scenes, however, things work much differently.

Building Uncertainty Ranges

No two projects are exactly the same. Even if you feel like you’re developing the same solution, there are too many variables at play to borrow from another experience to build your estimate. Comparing one project to another can be good for getting an order-of-magnitude or “ballpark”-level estimate. However, you wouldn’t want to make firm commitments based on just a rough comparison.

Adding Non-Development Factors

Not all of the effort in a project is spent by developers. Our project management team works hard to ensure communication remains open and transparent and keeps projects running smoothly. They need time to accomplish their tasks. Especially going into a new client relationship, no one knows how much time and effort that will take. Some of our clients appreciate a daily update email and have few questions. Others like detailed explanations on how things work behind the scenes.

Projects also vary widely in how much support they need; for small projects with a single developer, a project manager may stay a little behind the scenes, making sure the developer has what she needs and sending periodic status updates. In larger projects with multiple developers, multiple client contacts, and a multi-step testing process, the project manager is heavily involved every day. He or she leads scrums and meetings, facilitates communication and monitors overall project risks.

Besides project management, an estimate should include time for meetings, both internal and external, for quality assurance activities and for work necessary for deployment, to name some of the major non-coding categories.

An estimate that fails to budget time for activities like testing, internal and external communication, and project management, may only come up slightly short for a smaller project. However, it will leave a major gap for a large effort.

Foundation Phase Estimates

If a project requires up-front design and discovery work (and most do), you also need to account for business analysis time.

During our Foundation phase activities (also known in the industry as “discovery and design”), our business analysts work with clients to uncover their biggest challenges, opportunities, and goals and then build a plan to address the highest-value features and capabilities during solution development. As we wrap up design and discovery, our developers build a more accurate estimate of hours based on their lessons learned and the emerging solution blueprint.

(In fact, we often provide mid-foundation in addition to post-foundation estimates to help put our clients at ease and promote the transparency required for successful projects. Each one gets more and more accurate and therefore encourages better client communication.)

Consider Task Size

When estimating items, smaller is definitely better. Most of us can’t reliably estimate pieces of effort that are bigger than a day or two in size. If your estimate has an item that says “manage invoicing, 20-50 hours,” you’re going to be well-served by breaking that into smaller units of functionality. This can include “Create Invoice,” “Print Invoice,” “View List of Invoices,” and so forth. If the project has several types of invoice, each with its own print format, then you can probably break “Print Invoice” into smaller items, one for each invoice type. If it’s too soon to break that item maybe it’s too soon to estimate it; or, if 20-50 hours “feels” right, just be aware that you’re estimating based partly on intuition. Make sure your estimate has a range that allows for the fact that there’s more definition yet to do.

Number of Estimated Items

The number of estimated items matters too. The fewer tasks you’re combining into an estimate, the less meaningful your estimate is. Nobody estimates items right on the nose. We’re either over or we’re under, for any given item. With a large number of items, we hope that the overs and the unders balance out. Too few items, and your estimate risks being derailed by a poor estimate for a single item. We abide by the rule of ten: estimates containing fewer than ten items are very dubious. However, the farther over 10 items you go, the more stable your math gets. For best results, try to have no fewer than twenty.

Size of Estimate Ranges

Just as important is for all of your estimate items to fit within a certain range of sizes. Huge disparities between your biggest and smallest estimate items suggest either that the small items have been broken down prematurely, or the big items are not yet broken down enough, adding uncertainty to your estimate and the project as a whole. As a rule of thumb, we try to have a range of no greater than 6x between the smallest and largest items in an estimate.

Incomplete Tasks Lists

Estimation is all about finding something to count; your estimate is only valid to the extent your list of work items is complete. If you’re missing 20% of your tasks, it doesn’t matter how good your estimates for the rest are. You can’t possibly know how many hours you will need for what’s not there.

This is why our team prefers to make multiple estimates and only feels confident making commitments based on an end-of-foundation phase estimate. Once we’ve gone through a thorough foundation for a given body of work, we feel pretty confident that there are no major items that are completely missing from our list.

Using the Right Tools

To help our team estimate projects more effectively, we built a tool to put these ideas into practice. It uses some simple statistical math to create a master estimate out of a collection of work item estimates. These estimates could be generated by a single developer. Or, in a project with multiple people doing different kinds of work, the estimates could come from separate estimators. The tool can merge the estimates of multiple estimators. Just remember that, as with all estimation, the best estimates are created by the people who will actually do the work.

We believe successful businesses are built on efficient solutions, so how could we not build one for ourselves? We call it our Three-Point Estimator.

What is the Three-Point Estimator?

To provide our clients with accurate estimates, we built a custom solution for our projects. It starts with a set of line items representing individual work items; usually, these are user stories, though occasionally they represent necessary technical tasks. Estimators give each item three different estimates. One number represents the “expected” or “most likely” case — if everything goes reasonably well it should take about this long. The other two numbers are a best case (if things go perfectly) and worst case (I can’t imagine it taking me longer than X).

The algorithm then measures the span of this range. Wider ranges indicate more uncertainty in the estimate, while smaller ranges indicate more confidence. Finally, the algorithm combines the line items estimates into an overall estimate. Just like the individual line items, the overall estimate is a range. Generally, we don’t consider overly optimistic scenarios. We focus on project outcomes that, according to our tool, have a 60-90% chance of occurring. Sharing optimistic scenarios that only have a 1 in 3 chance of coming true, say, doesn’t serve the project well.

Of course, we are always working toward more concrete numbers. The more work we do on a project, the closer we get to accurate numbers. This is why we often have a project-start estimate but provide a much tighter estimate following our Foundation phase. We’ve learned enough about the work through extensive conversations with the clients and end users to minimize uncertainty in our estimated ranges for hours of work required.

Building Your Own Estimates

During your project estimation, I recommend keeping these principles in mind:

• Your biggest risk is not in mis-estimating an item on your list — it’s in having no estimates at all for items that aren’t on the list, but should be.
• Good estimates start with lists of at least 20 distinct items.
• Estimated items shouldn’t vary too widely in size.
• Budget for non-development activities like meetings, interviews, project management, user acceptance testing, training.

Then have a group meeting for a frank discussion around uncertainty in the project. Consider big gaps in estimates and what you need to know to reduce them. Then either track down that information or discuss and plan for best and worst case scenarios.

Good luck with your next project estimate! Let us know if you have any questions in a comment below.