“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
–Dwight D. Eisenhower

Why we estimate

Suppose you’re preparing for a trip and deciding which suitcase to take. You have a small suitcase that you like because it’s easy to carry and will fit into an airplane’s overhead storage bin. You also have a large suitcase, which you don’t like because you’ll have to check it in and then wait for it at baggage claim, lengthening your trip. You lay your clothes beside the small suitcase, and it appears that they will almost fit. What do you do? You might try packing them very carefully, not wasting any space, and hoping they all fit. If that approach doesn’t work, you might try stuffing them into the suitcase with brute force, sitting on the top and trying to squeeze the latches closed. If that still doesn’t work, you’re faced with a choice: leave a few clothes at home or take the larger suitcase. —Steve McConnell, Software Estimation: Demystifying the Black Art

As an engineer, nothing pleases me more than rolling up my sleeves and writing code. But before doing that, a sense of how to approach a task and the required resources (people, time, software licenses, third-party API access) need to be determined. These details support clear project expectations, which are foundational to the great client experiences we strive to create. Estimates, give all project stakeholders—internal and external—a chance to agree on a few key things before work is begun:

• That we understand what is being asked for;
• That we have a plan to efficiently deliver quality results;
• That we’ve asked (and answered) all project team questions;
• That we’ve considered all the risks, edge cases, and alternatives;
• That we’ve considered the effects on usability, accessibility, and SEO;
• That the available budget and desired timeline support the approach.

Quite often, larger estimates become the centerpiece at the negotiation table, kicking off a process of scope narrowing, prioritization, and concession. At 10up, we create two estimate documents for every project or large feature: a Qualitative and a Quantitative document.

The Qualitative Estimate

An estimate is an artifact. But it stands at the end of an estimation process. Here at 10up, the Qualitative Estimate document is where most of the process happens, wholly inside of Google Docs for easy collaboration; it’s rare for an estimate to be the work of a single contributor. The resulting document should be born of friendly arguments, constructive collaboration, and the benefits of Team 10up’s diverse skills and backgrounds.

The Qualitative Estimate provides two things:

• During the estimation process, it gives the team a space to flesh out the approach.
• Once complete, it provides internal stakeholders with proof of a workable approach.

The Qualitative Estimate requires more detail than a proposal or pitch might include. Each line item needs to be well-thought out and accompanied by specific details that might include:

• Restating the task in the writer’s own words;
• Identifying the client’s underlying business reason for the task;
• Questions and answers from the Discovery process, calls, or Basecamp threads;
• Our planned approach to the task including libraries, major components, and a high-level overview of how the code will work.

The amount of detail is relative to the task. There’s little sense in writing a three-page explanation around a clickable site logo. A more important component or feature demands considerable detail to back up the high number of hours it is anticipated to take.

The end goal of this process is to quickly narrow what Steve McConnell calls The Cone of Uncertainty. As a project progresses from raw ideas to a finished product, each step moves the team closer to an understanding of how much time the project will take. It’s preferable to work with a client early in a project to ask for more hours than when close to launch. By then, the client has already scheduled training, bought advertising, and/or spent the rest of the budget elsewhere. More details and up-front planning contribute to estimate certainty and help everyone manage expectations.

The Quantitative Estimate

The Quantitative Estimate is a more traditional spreadsheet. It’s broken out into major groups of functionality, with room to add line items describing the individual tasks within those bigger units. Each line item challenges the estimator to consider the efforts for:

• Front-end engineering;
• Back-end engineering (including Systems);
• Design;
• QA and code review.

Subtotals and totals are computed automatically, giving immediate feedback on the impact a task has on the whole project. This instant feedback loop breeds experimentation, estimating different approaches to see how the alternatives affect the grand total. This is important information to share with the project team so that different options can be presented to the client.

A rule of thumb for QA/Code Reviews at 10up is to start with 20% of the sum of the other disciplines, rounded up to the next quarter-hour. So, a task needing four hours of front-end engineering, 12 hours of back-end engineering, and one hour of design would be calculated by 17.0 * .2 = 3.4 hours, rounded up to 3.5 hours. But that’s just a starting point; the estimator can raise or lower that number to reflect the complexity of the task.

Tasks often end up taking more time than expected. There is no shortage of platitudes about this: Take your estimate, double it, then double it again; Multiply every number by 1.5; Multiply by pi and convert to the next time magnitude (one day = 3.14 weeks!). But to cite specifics, a study (Jenkins, Naumannm, and Whetherbe, referenced by Michiel van Genuchten) noted that, of 72 projects surveyed, “the average effort overrun was 36%.”

The Programmer Time Translation Table by Anders Abel tries to map programmers’ initial estimates to a more realistic amount of time, taking into account common issues that occur when working on a task. Note how important it is to account for time spent outside a text editor or IDE.

The last line of that chart is important: a huge task, one expected to take more than a couple days’ work, is too big to estimate with a lot of certainty. In order to narrow that Cone of Uncertainty, the task needs to be broken down into smaller line items.

Steve McConnell advocates a very scientific approach to estimating. 10up embraces a more agile and nimble workflow than this more rigorous method can accommodate, but the first half of his book Software Estimation: Demystifying the Black Art is full of wisdom on the whys and hows of estimates. It includes a list of things engineers tend to forget to account for when estimating:

By developing estimates through qualitative and quantitative processes, we’re able to provide more confident project pricing for our clients, minimize surprise budget overruns, and avoid the temptation to over-promise.

Further Resources

• Software Estimation: Demystifying the Black Art by Steve McConnell
• Professional Developers Estimate Times by Anders Abel
• Nine management guidelines for better cost estimating by Albert L. Lederer & Jayesh Prasad
• Why is Software Late? An Empirical Study of Reasons for Delay in Software Development by Michiel van Genuchten

https://www.youtube.com/watch?v=s9AFpnvkmyM