How to respond when you are asked for an estimate?

  • 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?

    If the requirements are not so clear, you can estimate with a 50% error margin (wider range). If the requirements are clear, you can estimate with a 20% error margin. Another good strategy that worked for me is to split a project into stages. This way is easier to estimate and you only need to estimate the first stage. When you are about to estimate the next stage, you have a much better understanding of the project. Also, trust between you and your contractor should be better. I also always write my assumptions and preconditions. Never write "it will work on IE8 or higher", be specific.

    Sergio, "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." How much do you feel improved today?

    Great link, Sergio. I could not map this philosophy entirely to my current situation, but I'll keep it in mind.

    I think it's also important to see the nuance between "estimates" and "deadlines". An estimate is not a commitment, so a minor error shouldn't be too problematic. I wrote a lengthy blog post about this here in case anyone is interested: http://marcgg.com/blog/2015/08/27/deadlines-estimates-software-startup/

    You may want to read about the "Cone of Uncertainty"

    Maybe the pareto principle could help? 80% is preparation, and 20% is actual work. From the past, look at how much time you needed to write a certain amount of code, multiply that by four and add that time to your initial estimated time.

  • 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.

    This is also a big part of McConnells's "Black Art of Software Estimation". *Never* off-the-cuff it.

    I haven't read Black Art of Software Estimation yet. Its the only Steve McConnell book I haven't read (well, I've never read After the Gold Rush, but I did read the second incarnation of it - Professional Software Development).

    I highly recommend the McConnell book. If possible, ask anyone who needs an estimate from you to take his estimating quiz: http://www.codinghorror.com/blog/2006/06/how-good-an-estimator-are-you.html You can present it as a game, but it often helps to get the message across.

    You can *always* say "I'll get back to you." If someone says "Well, I need an answer," say "If I give you an answer now, it will be a lie. I do not have enough information right now. It would be a disservice to us both for me to make something up on the spot."

    @AndyLester - plenty of situations arise where if YOU don't give an answer now, someone else will, and either take the project and the money with them, or still pin the blame on you in the end for missing an estimate you had nothing to do with. It sucks, and it's wrong, but it's unfortunately reality.

    @MadKeithV I have never been in that situation, and I've sat in and been involved with multiple project proposals for multi-million dollar contracts on both sides of the fence. In fact, in my experiences, after an RFP is published, the bidders have ample time to review the documents, ask questions, and produce estimates for cost and time.

    @ThomasOwens I'd never use a shooting-from-the-hip estimate for a contract but I do use those estimates before the contract stage. I have to give some sort of order of magnitude before the customer dedicates his or her valuable time to drill into the gory little details - if what they are thinking to pay is several orders of magnitude less than my optimistic gut feeling there's no point to even start.

    @MadKeithV That concept is foreign to me. Perhaps it's just not how it works in the defense industry, or at least on the types of projects that I've worked on. There's just an RFP, some back-and-forth, and then bids. The customer creates some type of conops document or system requirements and draws up an RFP. Then, bidders review these documents, ask questions, and eventually submit a bid. I've never seen pre-RFP discussions, although I have seen RFPs that just go nowhere because of what the bids look like.

    I usually take my personal (accurate) estimate, and multiply it by four or five, it has the advantage of being both competitive AND relaxing. But then if you're not ten times faster than most people, this won't work.

    A much better question in this situation is "When should I ask you about the estimate again?" - sometimes this will require a second derivative answer: "I will know answer to THAT in three days." It rarely goes more meta than this. Otherwise, I'm giving a wiiiide bracket: "Anything between an hour and two weeks. We're searching; it's an hour since found until fixed, but it first needs to be found."

    And there's always... "It's six hours of work. Now when will these six hours of work be scheduled, that's out of my hands, talk to my boss."

    Statistically we under-estimate by 30%. So just multiply your estimates with 1.3 and it should be accurate :)

    "Determine the accuracy that you need" should be changed to "Determine the precision you need". Sorry to be pedantic but it's a really really important point you are making here. The biggest challenges I see around estimates is the lack of understanding of precision and accuracy and how they relate to each other.

    +1 take time to make a decision. If your employer won't allow you to make an educated guess, then they are bad at their job and shouldn't be working with software developers. I always split my task into sub-tasks, decide how long each sub-task should take given past experience, then add 1 day for each sub-task for expected technical debt. Then I give it to my boss. If he wants it done sooner, he can choose what feature to cut.

    When did suggesting that one purchase a book become an acceptable answer?

    @JorisTimmermans This is true, but usually if stakeholders prefer someone who gives the answer "now", it means they are bad and this is a project doomed to fail. You have all to gain by staying out of it.

    @DarioFumagalli I disagree that you always have "all to gain" by staying out of it. If you're a freelancer and you need the work, then taking on a sensible amount of extra risk (in the schedule) for an actual paycheck and food on the table can be a very sensible choice. There are other factors at play too, such as "how much could I deliver to make the customer more flexible in allowing slippage from the original schedule". I do prefer to work on projects where planning and estimation is done properly, but sometimes that's an unaffordable luxury.

    I am a 1 man operation, I've learned over 35 years that a bad deal is a bad deal and "desperation for food" does not turn it into a good deal. If you are forced to do it by lack of other work, then do it. But if you have a choice, don't.

    How do you track your estimations?

  • 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!"

    How long does it take to write good requirements?

  • 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.

    That sounds like a very adequate technique. In fact, when you are making an estimate for your own company the estimate time is being paid as part of your salary also. I'm afraid, however, that the problem is that most organizations want estimates of much bigger tasks than the ones that can be expressed in .1 hour chunks. Thanks for your answer. (Are you the same Kyralessa from the joel on software boards?)

    Yes, the same one.

    @SergioAcosta the point is you use the analysis/estimation time to break down the task into smaller chunks. This is the best answer, imho.

    So if it is like 5 months project you should be estimating it for a month or more. Probably managers will not accept that :)

    @Darius.V, you make a good point. In this case the client's decisions were Yes or No to particular features, not an overall Yes or No to the entire project. This technique is certainly more challenging if doing the entire project or not depends on the overall estimate. On the other hand, if you're budgeting for six months for a project, but the project might actually take a year, would you rather find that out after six months, or after two or three?

    @Darius.V yah your comment actually makes sense, that's why you get those RFPs in which they want a detailed proposal sent back. I didn't really get it until this particular post detailed out for some reason. You end up screwing yourself over if you don't do the due diligence as the tldr;

  • 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.

    When they say it's too much, I pretend to think for a minute then say, "You're right! it is 18 months and 2 million".

  • 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.

    This is a great answer, it gives me very useful insights on how to estimate and consider things , thank you

    I read this answer 5 years too late. I once had a fight with my former boss reprimanding me for being off 3 days on a 14-days estimate.

  • "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.

    Probably this is why most of teams do 2 week sprints :)

  • 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.

    Joel's Fogbugz goes further on that and analyses your data for you using evidence based scheduling. Ie, each developer enters how long they think each task will take, and later, how long that task took, and it guages how accurate each developer is with their estimates to produce a probability curve for a finish date.

    Yeah, then do some GDD - Gauge Driven Development and ruin everything

  • 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.

    +1 for the need for on-going communication. IMO, this is **the** most useful part of the Agile model.

    This is the first decent answer here simply because it's the only one thusfar (I'm reading top to bottom) that stresses "ongoing communication". Everyone else seems to think estimate-communication is a one-off event. That's bad advice, and a poor approach to these things. *This answer* is good advice.

  • 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).

    Yay planning poker!

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM