How to respond when you are asked for an estimate?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/648

Question

We, as programmers, are constantly being asked 'How long will it take'?

And you know, the situation is almost always like this:

  • The requirements are unclear. Nobody has done an in depth analysis of all the implications.
  • The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.
  • You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
  • The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
  • No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked for an estimate and they expect you to give a reasonable answer. It's part of your job. You cannot simply say: I don't know.

As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does.

What is your personal process for deciding and delivering an estimate? What techniques have you found useful?

Was it helpful?

Solution

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

  • Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
  • Make sure you understand what is being asked. Determine the scope of the problem.
  • Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
  • Calculate the estimate based on your model.
  • Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
  • Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.

OTHER TIPS

Software estimation is the most difficult single task in software engineering- a close second being requirements elicitation.

There are a lot of tactics for creating them, all based on getting good requirements first. But when your back's against the wall and they refuse to give you better details, Fake It:

  1. Take a good look at the requirements you have.
  2. Make assumptions to fill in the gaps based on your best guess of what they want
  3. Write down all your assumptions
  4. Make them sit down, read, and agree to your assumptions (or, if you're lucky, get them to give in and give you real requirements).
  5. Now you have detailed requirements that you can estimate from.

It's like my mother used to threaten when I was a kid "Hurry up and pick out some clothes, or I'll pick them out for you!"

I did development for a guy who was very adamant about wanting accurate estimates. What we settled on, which worked very well, was this:

  • I billed for all the time I spent estimating. It came to around 20-25% of what I billed.
  • I did extremely detailed examination of the tasks. No shooting from the hip. I went into the code, figured out what lines needed to be changed, what other parts of the program it would affect, how much testing I'd have to do to ensure that things still worked. I'd estimate each piece in units of .1 hours (6 minutes).
  • I sent him my estimate for each task along with that detailed breakdown.

20-25% of billing sounds like a lot.

But he'd ask me to make change XYZ, thinking it'd take about 2 hours. In 1 hour of detailed estimating, I'd determine it'd take 8.5 hours. So he'd decide whether it was worth 8.5 hours of pay. If not, then he saved 7.5 hours over what it would've cost him if I'd done it without an estimate.

And if he did want to invest the 8.5 hours, the detail work I did for the estimate was work I'd have had to do anyway.

I found that with this method I was able to bring most tasks in on time or even early, without having to heavily overestimate. Because the time was broken down so minutely, I could tell early on if I was slipping. If I hit roadblocks so that after 3 hours I could tell that my 8.5-hour task was going to take 12, I could talk to him about it before more time passed so he could reevaluate and yank the feature if he was concerned about the cost.

Was he nickel-and-diming? No, I looked at it as letting him apply his money where he saw the most benefit. And I was glad to get experience in estimating, which I'd always been terrible at.

We're often asked for an "ballpark estimate" during meetings where we're given very broad and vauge ideas of what they'd like to do. I always say, "if you want an answer today it's a year and a million dollars. If you'd like to give me a lot more details and some time to review them then I can refine those numbers for you."

They almost always get the point.

It depends on what the estimate is for.

For an initial, high-level estimate for a business case then the key things are:

  1. Speed. Whatever method you use it needs to be quick. The whole point is the stakeholders aren't sure if it is even worth doing the project - which is why they need the numbers for the business case. If the business case was solid they wouldn't need your estimates. The bulk of these projects won't go ahead so it is important that too much effort isn't expended providing the estimate.
  2. Give a range. Make it broad. You have had no time to analyse requirements, workshop with stakeholders, validate assumptions. A wide range tells the recipient of the estimate "Software projects are naturally complex and risky - if you want a proper estimate you need to give me more details and more time". The problem with giving a single number or a narrow range is that it paints you into a corner by setting expectations before any real analysis is done.

I find the best technique to pick a comparable project that "feels" the same. "Feel" is completely subjective - but with this kind of estimate my experience tells me you won't find objective measurements. Then provide a wide range. I've read some books that say a range of -50% to +100% is good but it depends on many factors.

For a detailed, low-level estimate:

  1. You need a baseline. If the baseline isn't stable the estimate is meaningless.
  2. Bottom up is best. Get a detailed work breakdown, estimate each component then roll it up into a larger number. I find planning poker to be a great technique here.
  3. Document contingency. Make it clear where any contingency (if any) is added. Is it added to each line item? Or to the whole estimate? Or to specific risks? Or is there none?
  4. State your assumptions. Validate as many as possible given the time frame.
  5. State explicitly what is included and excluded in the estimate. For example, is review included? Are technical delays included?

Some advice from the dark side from one who learned the hard way.

The requirements are unclear. Nobody has done an in depth analysis of all the implications.

Don't do an estimate at this point. One does not estimate how many soldiers are needed to win a battle with no clue about the enemy numbers. The estimate is made after scouting. This is unless you already fought this enemy.

The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.

This is your responsibility to factor in unless you expect others to have the expertise about this area.

You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.

Same as above, even for unanticipated work that's created by a slob team mate next to you with a near non-existent test procedure which causes your code to glitch out that you can't perfectly predict in advance. It's a weather forecast.

The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?

Understand the user-end requirement here, think like a user. Don't do what your peers do if they estimate something to be "done" just because some basic functionality with a barebones workflow that no user can possibly tolerate is what they consider to be "done". Think of it from the user standpoint, because that's all the client you're making the estimate for will typically understand. Estimate towards the complete user-end requirements, not towards the barebone technical requirements. And realize that your clients asking for estimates will be totally inaccurate here about how they word things and understand the technical aspects of what you say.

No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Don't do this! You sound like a self-motivated hard worker and possibly one who gives in easily to coercion.

The problem here is this: let's say you and Joe made time estimates for the same task (but between two separate employees, unaware of both estimates at one time). You estimate valiantly, "one week". It's okay you think, you'll work over 100+ hours a week, unpaid overtime. Now you're three days late.

Meanwhile, Joe estimates 5 months. You think this is ridiculous, you think you can pull this off in one week. How much does Joe work? 10 hours a week? ... except he finishes on time in exactly 5 months.

Guess who gets perceived as the jackass? That's right, you. Joe seems like a great worker, you seem unreliable now. It doesn't matter so much that you might have achieved an even better result in ~7% of the time that Joe took. What matters is that you were 3 days off from a one week estimate.

Never err on the side of the tighter estimate. Err on the side of the looser estimate. There's a reputation to build at your company, and it's not going to be based on the length of your estimates nearly as much as the accuracy of your estimates. It's easy to be accurate with an estimate that's too long, you just get more time to work on the problem and solve it better. An estimate that's too short leaves no breathing room at all, you either meet it desperately or you're screwed.

"Two weeks!"

Seriously. My first estimate is always two weeks. Because I have some sort of bizarre mental block that makes me think everything sounds like it'll two weeks.

I try to work around it, try to really think about how long I think something will take, trying to identify all the potential trouble spots and bits that look too black-box-y for me to be accurately estimating. And try to recognize that if my answer is "Two weeks!", I've likely failed to do so.

Pretty much every good manager I've had has learned to recognize "Two weeks!" as an answer that requires a mild verbal pimp-slap in response.

There is a blog entry that outlines how to keep a record of how accurate your previous estimations have gone, and then next time you say to someone "it'll be two weeks", you can look at your previous history and see how long it actually took last time you said "it'll be two weeks".

I haven't tried it myself, but I'd like to, to see how accurate my estimations are.

It depends on the organization and how the estimates are used.

If the estimate is just to provide a general idea on when it will be ready, I can generally do a quick estimate based on my experience. Often times I will include any uncertainty or possible variations with the estimate along with how the changes may impact other areas of the system and the extent of regression testing required.

If the estimate is used for anything contractual or in a scenario where more precise timing is required, I do a full work break down. This is more work and requires more in depth thinking about the design and changes to the system, but is much more accurate, especially for larger pieces of work.

In either case, on-going communication is key. If you do run into something unexpected, make it known at the time instead of waiting until the deadline. If the requirements are not-clear, make sure you document your understanding of them and the functionality that you plan to deliver. This is also helpful with any assumptions you make. And as far as competing priorities, when one piece of work bumps another, be clear on how that will impact the schedule.

Estimates for what? Small tasks or complete solutions.

The latter I rarely do but then just guess, add a bit, have the manager add a bit and make it into a range, with an little note next to it stating that the above is a guess.

Small tasks - Planning poker I've found to work really well (not perfect, some 1pt tasks have taken much longer and some 5pt tasks took minutes, but it all evens out in the end).

Present a range based on what you know today. Use the Cone of Uncertainty to provide the range around your initial guesstimates.

Every week calculate how much is left to do, re-estimate based on what you know. Once you have enough of a sample size of how much work you are getting through each week, provide a 90% confidence interval for what's left to give a (usually) ever narrowing date range as the project progresses and the amount of work left (hopefully) shrinks.

Confidently. I can't tell you how many times I botched up an initial meeting with a client by not putting on professionalism when giving an estimate. Even if you're blowing numbers out of thin air - make sure you always keep some estimate around. That said, be careful not to estimate yourself into a hole. Different things take different amount amounts of time, effort and resources to put together. Here's a good way to do it:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

Sometimes estimating becomes an enormous challenge for you and your team, especially when we are talking about software project estimation.

Once we had decided to share our experience and our knowledge about software estimation process and defined four distinct types of estimations:

  • ballpark figure
  • service estimate
  • feature estimate
  • componential estimate

Of course, those types are distinct. Ballpark is what is often called a “guesstimate”. So it's an approximate number or range that gives a general idea of cost and that may help a prospect decide whether they would like to take the discussion further.

As a rule, clients need a ballpark figure at the beginning of the project. And our advise is: discussion of the project and providing ballpark figures should just be steps well towards receiving componential estimate (which is flexible, one can make use of componential type estimate for the whole development process. No need to re-estimate from scratch when you want to add, remove or replace features, services etc).

Everyone should keep in mind the risks that come with software development estimating: underestimating, overestimating, total epic fail scenario etc.

You can read more on our blog!

http://blog.lemberg.co.uk/project-management/software-estimation-process/

Hope this information will help you!

I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again.

It sounds like you're being asked for a commitment, not an estimate. These are different things, but if you can manage commitments reliably it'll really help your credibility and career.

Some advice based on my ~10 years of experience:

  • Always provide a range (i.e. lower and upper bound). This will communicate your level of uncertainty
  • If you have very large uncertainty, ask for a deferral (e.g. 1 day to do analysis, and then provide a tighter range)
  • If the task it too large, break it up and provide a range for each piece

First, if some task was assigned to me I would break it down into subtasks.I would estimate the time for each subtasks and probably with subtasks I would be able to find the problematic area and hence I would be able to forecast how long it would take to a certain extent.

But still all the planning would help only to a certain extent. Only when you start coding you can find the exact issues

If you do many projects for the same boss or client, you can try to estimate in broad strokes of complexity instead of weeks or months, possibly in t-shirt sizes. Identify a few past projects, and assign them the sizes S, M, L, XL.

And then ask yourself: which project does that sound similar to in scope? And then instead of answering with "2 Months", you can answer with "sounds like an L to me" (or whatever your calibration for project turns out to be).

This is pretty easy to understand, and it is also clear that there is lots of uncertainty in those guesses.

Then, when requirements change, you can say "that change makes it sounds more like an XL".

A bit late but when I was in the military we were instructed to use PERT to determine estimates. It does require some experience in your field and the task at hand. It was surprisingly accurate when determining estimated time of completion when maintaining and repairing electronic devices (complex radios and satellite comms equipment), where any number of things can be wrong or found and needed to be fix during routine maintenance. The estimations were important because other units may be inoperable until they received back their comms equipment. One that I've used is this Free Online PERT Calculator

Licensed under: CC-BY-SA with attribution
scroll top