When it comes to the topic of estimating, my favorite line to throw back at the sad soul who is asking for some intangible number is - " I'll see your vague, my friend, and raise you a wide open". Being the gracious hostess that I am, I like to follow that up by offering a random number chaser. "It's going to cost this much" where the span illustrated by my hands is as much a figment of my overactive imagination as the thought that you might truly possess a full understanding of the project scope you want an estimate against.

Simply put, estimating is hard. Good estimates ultimately are a reflection of good information. Admittedly there are times, where as a developer, we are not privy to all of that good information. We've all been exposed to the mythical figure - where there is some elusive magic number that is having a professional pinball game in someone's pea brain. This number does in fact exist - at last call its going to cozy up and go home with the line item labelled "total" in the estimation sheet, and the fact of the matter is, as a developer, you're going to be the last one to know.

For a developer, the frustration lies in the Calvinistic nature of this process - if we knew the number existed and was predetermined - would we really put in any effort in trying to change this? I'll take apathy for 1000, Alex.

Its up for debate which is the lesser of two evils - underestimating or overestimating. Overestimating at times encourages inefficiency- people will take as much time as they have to do the task, regardless of if the task requires that amount of time. Underestimate and suddenly someone has to gracefully swallow the cost of overages along with every developer's favorite result - a compressed time line earmarked by unrealistic expectations.

The estimation process cannot be subject to the game show mentality - where the closest bidder is rewarded by being allowed to draw warm crumpled bills deep from the pocket of some well-preserved, retirement-expired neutering advocate. Sound creepy? That's because it is. If a number exists, regardless of its context or definition, that in of itself provides scope- and therefore is essential information for a developer to know prior to making an estimate. The operative word here is prior - so often I have taken the time to make an estimate only to find out that the magical number was going to grace us with its presence. Refactoring -not just for code....
ﾠ
I often have a habit of comparing a project process to a relationship on many levels.The better, more mature version of me, thinks that the ending of a relationship or project should be treated with the same respect in which it was started. Neglecting the estimation process by kicking it to the curb without slowing down the car is a sure sign of the probable success of that project. Estimations are most often how a project is started - a bad estimate brings nothing to the table but bad information. We can all place our bets at ten-to-one on bad planning - there is a reason why its much easier to find the window to make that bet, than there is to find one that pays out.
ﾠ
Developers generally, well, they generally suck at estimating. Its not a natural skill for most developers or most people in general - its a learned one that takes much time and practice. The only way to get better at estimating, is by estimating more. Developers in particular, often estimate in ideal hours. They think about feature completion, not necessarily process completion. The definition of done becomes ambiguous - for done might not encompass other integral tasks such as quality assurance or documentation. A developer quote. most often is for the "doing" part of the project but not the actual process of doing itself - developers tend to remember only the books and not the bookends. The development process itself can be viewed as a triad comprised of planning, execution and testing. Each task, in theory, draws from this triad - a developer plans how to do something, spends time doing it and then ensures it works how it should - proudly hands it over and resumes their sweat pant wearing existence.
ﾠ
How do developers level up in estimation to gain experience points to learn new skills or acquire abilities outside of affliction and demonology ? Developers need to practice estimating - and a good place to start with is the smaller components of a project - both client or internal. Regardless of the task (within reason of course) a developer should be required to provide an estimate and held accountable for that estimate. Peer reviews for estimation can be useful as often items are easily overlooked and having another person with a critical eye can act as quality control.
ﾠ
One of the easiest ways to estimate a ballpark figure on a project is to draw the numbers from a previous project of a similar scope. Proceed with caution- often I've had a project manager say " its just like X project, but a -z is different". So... you mean, its exactly the same, but entirely different? It is human nature to draw comfort from familiarity - this often happens to the project's detriment in the estimation process. Before you know it , the orange is an apple because apples are easy to understand, and oranges - well oranges are just different.

Using a previous project as a baseline provides insight that could never be gained from taking the tabula rasa - blank slate approach. Its a quick way to gauge at least the level of effort for various parts of the project. On the other hand, it doesn't always apply unless you are fortunate enough to possess both a unicorn and the otherworldly project cookie cutter every sales person covets.

Another common approach to estimation is to treat it like you would happy hour - bottom(s) up . The scope is broken down into its smaller components and each one of those is estimated. Step aside old school addition, out comes the calculator to determine the overall number based on the identified components. Granularity doesn't necessarily equate to accuracy - its hard when taking this approach to not become some crazed extremist in search of the smallest, read useless, possible unit. This is definitely a more detailed approach yet it depends heavily on the definition of the project existing and not just in someone's brain trust. The reality is quite often, clients suffer from a bad case of ADD - if it glitters, its commandeered their attention. Sometimes, clients know what they want about as much as they think they know what they need and or like.

When a client wants a piece of string but has no idea the length of that string - its a good opportunity to help the client define not only what type of string they need but how long it should be. Its near impossible to accurately quote against a project that not only has some unknowns but frankly is an unknown. This is a good opportunity for a discovery phrase - to assist the client in determining what they need and how that need can be fulfilled. A complex quote such as this - does not get done in a day. If you need to say - let me help you figure out what you need, you also need to not be afraid to say - pony up and show me some green. Did I just suggest the unmentionable? Yes, I sure did.
ﾠ
Now onto ways to estimate better : take this for what its worth, I don't proclaim to have mastered nor demystified what is commonly referred to as a black art , but I do believe some of these items have made my estimates more accurate.

1. Estimate by range.

The glass is both half full and half empty. I make a quote that satisfies my inner pessimist. Then I make a quote as if someone pumped sunshine up my skirt. Finally I make a quote in the middle. It's the realistic granola crunching mediator for if these two polar opposite personalities ever met in person outside of a Jerry Springer "Daddy DNA" special.

Giving a range illustrates the worst/best case scenario.

2. Estimate in consistent units.

A day should be a day with X number of hours. People generally feel that doing hours is more granular - however as soon as one starts using days, it sets a level of expectation for completion - 30 days is not a month - 30 days is actually 6 weeks of 5 business days a week.

3. List assumptions.

Apply the whole overused rule about making assumptions - go ahead and make them, because without them, certain items will certainly get lost in the shuffle and in doing so it creates priority and accountability to a small degree. Make assumptions about items such as client deliverables, responsibilities, sign offs and deployment practices.

4. List and rate Risks.

Risks can be defined as that which is unknown. It can also be drawn from past experience. Rate the risk factor based on its impact against all the stakeholders. It is minor or is it really going to screw you over if all hell breaks loose?

5. Use object hierarchy/modelling to help estimation.

Break down the pieces and how they interact and estimate against that high level view.

6. Practice your grade 4 math by rounding up and using some multiplication.

When someone says "an hour" for a task , it automatically gets bumped up to half a day. If a developer tells you 3 days, multiply it by some factor to account for it.

7. Keep track of common elements that occur in projects and time associated with them.

This will let you evaluate the progress of both the people estimating against the work and those doing the work. Post project reviews are integral to this - keeping notes of what went wrong, what went right, what things could be attribute to overages or successes - they help the next time that process starts over again.

Estimates are not something that happen only at the beginning of a project. They need to occur throughout - if an item is out of scope and is requested by a client, it needs to be estimated to thoroughly communicate the ramifications of completing the new item - both in time and effort. Be wary, project managers, of obese estimates from developers at this point - apathy and opposition can easily be translated by a developer into a number that has much more than just junk in the trunk.

Read the rest of this series here.

Read more from Stacey Mulcahy.