16 ms·

How to respond when you are asked for an estimate?

253 points by lainon 9y ago

koonsolo 9y ago
Also: Is it an estimate or a deadline? Most of the time, you will give an estimate, and the manager will turn the sum of your estimates into a deadline. Don't fall into this trap.
- redler 9y ago
  I try to consistently use the word "target" to head off the ambiguous semantics around time estimates versus "deadlines". It's a little thing, but it can be psychologically easier if one explicitly controls the project language to allow "we need to revise our target" than to be implicitly seen as "not meeting a deadline".
didibus 9y ago
One thing I've been unable to ever see adopted is a true bottom up planning strategy, where the time to delivery is estimated from historical data. Say last X project took Y time, similar Z project will thus take Y time. And from there, the business plans timeline and delivery dates. The reason for this is that in practice I've found estimates are an indirect way to define scope. You need to ballpark the minimal viable product in a range from under a month, a month to 3 months, 3 to 6, 6 to 1 year, over a year. After that, its just about downscoping all the "good to haves" based on if there's time left from the desired deadline or not. As long as you delivered the "must have" in your timeframe it should be good.
- valuearb 9y ago
  The more work that is put into a planning process, the later the product will ship.
wolfgke 9y ago
It is common programmer folklore to apply the 80/20 rule to estimate the time required to implement a feature - and I don't mean the Pareto principle, but "Do a worst case estimate, add 80 hours and multiply this sum by 20". :-)
huffpopo 9y ago
Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At most companies estimates are about control, expectation management, and blame distribution and not about information discovery. Most people really suck at expectation management, much more than they suck at estimating work.
- honor_roller64 9y ago
  Triple it and then you have some headroom for when they halve it.
  - justherefortart 9y ago
    I make my best guess and quadruple it. That tends to be the most accurate I get. I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else. So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.
    - ghaff 9y ago
      An engineering manager I used to work with would drive me crazy. He had this "methodology" he referred to as a 90% schedule but it was a 90% confidence schedule only in the sense of no one ever getting sick for a couple of days, tests not failing, no hardware being defective, etc. etc. It won't come as a surprise that this schedule was basically never met.
  - patrickmay 9y ago
    Double it and go to the next higher units. 4 hours? That's 8 days.
  - paulie_a 9y ago
    Exactly. Never give a be range either. The lowest number is now your estimate.
glenjamin 9y ago
The best approach to this I have found is to ask why. What decision are you trying to make using this estimate? Understanding context helps you to understand what sort of estimate is needed - or whether an estimate is needed at all.
- Rabei 9y ago
  The question is to know how much it costs, sometimes they also want to know if they'll meet some external deadline.
  - convolvatron 9y ago
    I think what the GP is getting at is that an estimate in absence of a context is meaningless. The organization may just be trying to get a handle on the rough scope of a job to make strategic decisions. They may also be in the middle of a discussion with a customer about delivering a feature. The best thing for both the company and yourself is to try to be as high bandwidth as possible and discuss all the potential risks and tradeoffs. Find out what the real goals are so you can optimize a solution to provide for them. Many managers and customers get stuck early on with a particular approach, but if you apply some creative engineering you can come up with a solution which is easier, or folds in with some other goal you were already working on, leverages existing functionality etc. its on you to express it in terms they can understand from their own position: risk, cost, headcount, schedule, dropping existing features. if your organization doesn't want to engage in that kind of semantically meaningful discussion, or comes back and says 'I know you said 3 months, but get in don't in 2 weeks' then you need to start managing upward and looking for a new job. or you can just overestimate, and enjoy your free 2 hour lunches for as long as the money lasts.
vermooten 9y ago
I don't do estimates any more but I use forecasting. Like the weather, it's an idea of what might happen given what we know now. I once laughed in a job interview when the interviewer said that they expect 'accurate estimates'.
- valuearb 9y ago
  I would have responded "Then your dev process is broken".
WisNorCan 9y ago
There is a difference between establishing a deadline and estimating relative effort and complexity. The former is problematic. The latter is important and should be done and then revised continuously. The process of building software includes discussing what has the best impact to effort ratio. Both are estimates and will not come out as expected. The logical response to managers that expect you to always hit deadlines is to inflate estimates enough that you will.
rrggrr 9y ago
My flow adapted for this question: 1. Why do you need the estimate? Is it to get budget approval, or because you're trying to meet an approved budget? If they don't have budget approval then I'm going to charge them something to gather requirements and deliver an estimate. No budget approval = low on priority list. 2. We charge a blended rate of $xxx per hour. If you have a detailed requirements list I can tell you if we can do this within your budget. If they don't have a detailed requirements list then I'm going to charge them to provide one. After I have the requirements list completed I'm asking for their budget. 3. Don't want to pay for a requirements list? I understand. Its okay. Something like this typically costs (low bid), but that will likely change if the requirements are different then my assumptions.
- jlj 9y ago
  Could you elaborate on #3? Do you walk away at that point? A last attempt to show the value of good requirements and get them back to #2, else they are premtively "fired" as a client? Going to hold onto these. Good phrasing/ideas.
  - rrggrr 9y ago
    In enterprise software, at least the companies I know, they will underbid and return to the well many times for increases. They will blame this on poorly scoped requirements, for which they were not responsible. They will be right, and they count on this for much profit. If you quote virtuously, you will be a victim of your client and competitors who scope/quote less virtiously.
wruza 9y ago
At our company we didn’t estimate entire projects, but separated tasks until it was 3-5 hours piece of work that everyone agreed “it’s realistic, I can do it”. The big time then simply summed up with 30% buffer for delays. Since our customers mostly paid for hours, it was also a good base price builder. Big projects can suffer from this because little architecture is involved (and we worked on already existing systems). Otoh, I’ve seen no big local project that wasn’t an architectural mess once it hit a deadline hard. It is better to not have one than to have a set of rules that you must obey, while other parts of system don’t even care of or contradict these. Personally I don’t believe this “I’ll get back to you with an estimate” thing. It is just first iteration where you go relax and try to formulate at least 5-10 questions that you think you should ask foremost to start building an estimate. If you come back with an answer instead, then it is still wrong, maybe even worse than random, since you estimated a different thing. For us, estimates and requirements always moved, as they were functions of delays and business priorities that change unpredictably. I didn’t like to deliver the entirety on a deadline because my job was to support that for years, not throw a bill at them and run, as all integrators did. Maybe, maybe these SE-users are speaking about coding phase, when all “business analysis” was done perfectly. But ime it is you coder who collects all the knowledge, because no one can. Or it is you who is non-coding analyst who must estimate, because non-analytic coders don’t have a clue what a big picture is.
twic 9y ago
"Six to eight weeks" https://meta.stackexchange.com/a/19514/154820 https://meta.stackexchange.com/a/19514/154820
amelius 9y ago
Tell them there's a probability density function associated with the result. This allows you to get away with any outcome :)
christopherslee 9y ago
engineers hate giving estimates for a variety of reasons that i'm not going to get into here. most modern agile organizations don't value spending time on getting accurate estimates, but some kind of best-faith estimate is still valuable for a lot of reasons. for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is. for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z). or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day. what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.
- GordonS 9y ago
  I like to do something similar - I break down what I see are the risks, add a risk factor accordingly, then provide the estimate as a range. For example, the risk factor my be 50%, so I'll say the cost will be between £100k and £150k (for example). I find this really helps to focus the customer stakeholders who can control some of those risks.
- newfoundglory 9y ago
  Some devs seem to have actual phobias of estimates. My team was asked if we can deliver features x or x+ some time next year. (IMO as the dev who knows both the code and x best, we can deliver x in 2018 easily and x+ maybe). In our discussions about it, one guy would only say you can't predict the future, and another guy argued we should say either of them would take two years so that we could have time to rebuild the app from scratch while we delivered them. It's a web app.
  - christopherslee 9y ago
    tl;dr - we engineers are bad at estimation because we're too optimistic, and then we don't want to be accountable to the estimate given based on limited information. i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.) i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.
stesch 9y ago
Pro tip: Don't laugh. The boss once asked me for an estimate and I laughed. He said that wasn't funny and I said that he started it! On the other hand: Do it. Laugh. Laugh in his face when you are called to help on a project that isn't ready after 1 year and started without you. When they show some wire-frames and ask you how long it takes without telling you about the actual technology used for the project. Summer 2015 I was uninvited from a project meeting. My coworker was planning the project and discussed it a bit with me. He wasn't the one who decided that I shouldn't take part. Summer/Fall 2016 and the project isn't going anywhere. I'm invited to help. I do my best, besides the other projects. January 2017 and my coworker is gone. He gave his 3 months (+ x days) notice and told me December 2016. Shortly after it I gave my 4 1/2 months notice. The new deadline for the project was May 2017. They launched November 2017. "Cool story, bro. What was it? Some revolutionary VR or AR application? AI supported super gadget? Brainwave reader and interpreter?" … It was the company's own website.
- pjzedalis 9y ago
  I have been in a similar situation. Any project like this one can often go off the rails if the right decision makers are not involved. This is not necessarily the fault of the project leader as it can be unintuitive in bureaucracies.
  - redler 9y ago
    Corporate websites, in particular, can be pathological cases. The closer to completion, the more "stakeholders" come out of the woodwork.
- lkrubner 9y ago
  I've a similar story. May of 2015: hired at startup that wants to use Natural Language Processing so salespeople can send text messages directly to their CRM (Salesforce, PipeDrive, etc). Very excited about the project. The app's initial UI design is a traditional one, with NLP helping to smooth the basic task. The full app would take about a year to build but we all agreed we could have an MVP by August. August of 2015: without consulting anyone on the tech team, the Board Of Directors decides the app should get rid of all standard UI elements: no forms, no buttons, no links, no drop down menus. Instead, the interface should be a pure chat app. This makes the project much more ambitious, which I was very excited about, but which I felt would delay the project 2 or 3 months. Nobody was happy with my estimate. September of 2015: the CEO was able to show a demo to the Board Of Directors. The demo was an illusion, as we had no error handling, and it only worked for some carefully planned examples, but I thought it was a good sign that we could show the Board that we were making progress. Unknown to me, the Board then asked the CEO for real feedback from real customers at the next meeting, a month later, in October. There was no possible way for us to finish the product, and find customers, and get feedback, all in a month, but the CEO was a bit of a coward, so he promised the Board we would do this. October of 2015: obviously we did not have customer feedback by the next meeting of the Board. At this point the Board decides we have missed our schedule and they begin to panic. We are slowed by the fact that our "NLP expert" is inexperienced. Myself and our iPhone programmer tell management that we need to fire the current NLP guy and hire someone with real experience. Management initially agrees but then later changes its mind, for reasons unstated. November of 2015: we get a basic demo working, and it has enough error checking that we can show it to potential customers, and not be entirely embarrassed. But the stress of the previous month has wrecked relationships inside the company, people are shouting at each other constantly. At this point I step away from the project, but I remain on friendly terms with the guy who is doing the iPhone programming. January of 2016: company gets two trial customers, but these customers won't pay for the product. The NLP engine is improving, but at glacial speed, as the "NLP expert" is at the beginning of his career. He was a nice person, and I can believe he will eventually become a good programmer, but it didn't make sense that a company that wanted to move fast also remained so loyal to a guy who could not do what was needed. An established company could/should afford to have an apprenticeship program, but a fast moving startup can not offer an apprenticeship to someone working on a core technology. April of 2016: the iPhone guy again asks management to find a new NLP expert, someone who can move the company forward. Management reacts by listing every bug ever discovered in the iPhone app, as a way of telling the iPhone guy to shut up. May of 2016: the iPhone programmer quits and gets a job elsewhere. June of 2016: the company is almost out of money, so it cuts back on spending, reduces the team. summer and autumn of 2016: without much staff, the company crawls along at a glacial pace Early 2017: the company gets more funding, begins moving forward again. Summer of 2017: the company now has a few trial customers, but they are paying trial rates, which is to say, almost nothing. The company is not anywhere close to the breakeven point. The company continues to burn money without making much progress. There are clearly some fundamental leadership issues that should be addressed, and one of those are the ways that estimates and budgets are created. Also, the company would be in much better shape if the leadership listened to feedback from the tech team. I wrote about all of this in detail here: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/0998997617/ https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
falcolas 9y ago
My PM has a great way for dealing with engineer estimates: increment both the number and the unit. 1 hour becomes 2 days. 4 days becomes 5 weeks. And so forth. I'm actually somewhat decent at estimating well defined work, so it actually annoys him when one day is one day; but I appreciate his work when some odd stumbling block (usually political; my estimating skills crash and burn when it involves working with humans) comes up and the time doubles or triples the estimate.
- eps 9y ago
  It's a very old PM joke. The original version is "double fhe number, shift to the next time unit."
  - falcolas 9y ago
    The best jokes have their roots in reality. Of course, when the joke works in reality, is it still a joke?
    - eximius 9y ago
      Some of the best jokes are funny because they're true.
  - whamlastxmas 9y ago
    A one year project is now a two decade project
    - hrktb 9y ago
      Seems about right. A year is an eternity anyway, you shouldn’t start a project with nothing coming out of it before a year, that’s suicide on so many plans.
      - user5994461 9y ago
        A software project that takes a year will costs a fortune (salaries are expensive). It will probably have to be maintained and running for the next decades to give enough returns to be worthwhile. So, 1 year is the time the first interns team will work on it, 10 year is the duration before the project is retired. Looks like both estimates were right.
thomk 9y ago
Bill your clients for estimates and still give ranges. The more they want to dial in those ranges, the more billable time you spend estimating. "How long will it take to estimate" is a question you should be able to answer because you will control the deliverable in this case. Also, if you spend time with them asking questions and helping them discover the complexity of their request, they will soon see the benefit of this process. Alternatively what I'll do is point out that their request is simply incomplete and I can help them create a better request, which I will then estimate (it's all still billable though).
- redler 9y ago
  It's critical to position yourself (or your company) to be able to bill for discovery (a separate project, or at least a day-rate engagement). You're a consultant working with the client to figure out what the project actually is. Amazingly, the client often doesn't really know, as can become apparent during that first gathering around a whiteboard. And if they don't know, you're well on your way to a "now that I see what you've done, it's not really what we had in mind" moment.
  - rboyd 9y ago
    Great point. Also worthwhile is to consider the overall likelihood of success for projects you take on (and what it implies for future work, quality of life while working with the client, etc). I wasted a lot of time early in my career on projects that I knew were doomed just because someone agreed to pay my rate.
rogerbinns 9y ago
I give an estimate with an error margin, that is usually larger. eg something like "that will take about 3 weeks, plus or minus 2 months". The plus or minus bit reflects the uncertainty in requirements, things that could change etc. Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant. That is why I include the "minus" bit covering this scenario where a solution is already there.
- arkades 9y ago
  > I give an estimate with an error margin, that is usually larger. eg something like "that will take about 3 weeks, plus or minus 2 months" I can’t tell if you’re being serious. How do people respond to such a non-estimate?
  - LambdaComplex 9y ago
    3 weeks minus 2 months...I'd probably ask if that means it might be done already
    - rogerbinns 9y ago
      Yes, that was precisely the point with "Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant".
  - rogerbinns 9y ago
    I am very serious. My clients respond very well because it helps them plan better. The problem with a traditional one number estimate is you don't see the error bars so they don't know how to treat "3 weeks". My approach also helps start a discussion about how to reduce the size of the plus/minus bit, such as reducing scope, breaking into multiple pieces etc. And the minus bit coming to negative time works well too. It becomes a decision about using what is already there even if not perfectly suited versus doing the new work, and how much of it to do.
aorloff 9y ago
Explain that the way to do estimates is to have a process that starts by breaking down the work into the components of the design, estimating each component, and adding it up, with small padding to each granular component. The more granular the breakdown, the more accurate the estimate. For a single top-line complete project guess (which is what you are being asked) you should use a large pad, as comments below say, double and shift. If you can afford the time to do the breakdown, you will get a closer and more realistic number, and have some of the project planning work done to boot.
deleted 9y ago
[deleted]
gavanwoolery 9y ago
At my company we use simple analysis on previous estimates and adjust future estimates based on past errors. We are usually about 70 to 100 percent accurate using this method. However, projects are usually not more than 7 days of work in my case.
- GenSpecialist 9y ago
  This is something I wish I saw more talked about: how to get better at estimates. I wish more people dedicated time to reviewing their projection & mindset at the time, then look at the task timeline, then write down what caused it to go off schedule. Sometimes it's an environment change. Are these consistent? Can they be modeled statistically? Often, it's an inaccurate belief in the work to be done. Was it lack of requirements, that had to be expanded? Etc. When I work in development, I spent up to 20% of my time on "overhead" tasks. These are of the estimate review type, not meetings. It's something a great manager will do without wasting his team's time, but as an independent, I spend a lot of time doing it myself, and it's amazing how much it helps to dedicate time and write things down.
- valuearb 9y ago
  Why on earth would you waste a single minute doing any planning for a 1 week project?
sheeshkebab 9y ago
Oddly enough t-shirt sized estimates work well. get a sense whether task is S, M, L, or XL from developers etc... and then multiply it by whatever factor you think S-XL should be in hours/days. people can't seem to provide time-base estimates - but generally have a good sense of a complexity of a problem.
- redler 9y ago
  A similar trick to help crystallize thinking about the project is to ask whether it's on the order of hours, days, weeks, or months. This mitigates the fear of speaking a number and having it be enshrined as a guarantee, while connecting the rumination process to the experience of past projects in all their underestimated splendor.
  - wiredfool 9y ago
    I like this approach, especially for getting estimates out of trades that don't like doing estimates before they tear apart your clutch. "Is this a hundreds of dollars or thousands of dollars problem" can work wonders.
xahrepap 9y ago
I like to say, "my gut says X days. But I'll have to get back to you." I think there's a lot value in having the conversation with the PM or manager or whomever in the moment. And being non-committal is frustrating for the other parties.
- clooless 9y ago
  That "gut estimate" converts to a concrete deadline in your PMs mind before you put a period at the end of your sentence.
  - xahrepap 9y ago
    Not in my experience. I think it's about managing expectations. You just have to be clear about what you mean with that individual. If that PM takes it to mean that then you need to find another way to communicate your message. I think what I intend to say with that can be, "I don't know how long it takes and it'll take more planning to figure it out, but I'm willing to participate in this conversation so that we can continue to effectively plan in the current context." If the current context is "concrete" then you probably don't want to give a number. If the conversation is (and this was my assumption before) "here's a feature we want done but we're trying to figure out it's priority and feasibility" then giving a gut check adds value. You just need to be clear in your messaging. And if someone uses a gut check number against you "but you said X days!" Then you need to call them on it and make sure you explained the discrepancy.
kesor 9y ago
Just keep in mind that estimation != promise. Make estimations to help you plan your time, but never commit these to management who turns them into promises.
mikmoila 9y ago
Don't forget psychological aspects: http://www.cs.toronto.edu/~sme/papers/2005/ESEC-FSE-05-Aranda.pdf http://www.cs.toronto.edu/~sme/papers/2005/ESEC-FSE-05-Arand...
k__ 9y ago
The problem with estimates is mostly requirement analysis. When people say they need feature A, B and C and ask when I will have it done, I split it up in tasks that take below a day, estimate these tasks and add 50% for safety. This works in most cases. But often the reason why projects won't finish on time is, because people don't know what they want. They ask for A, B, C, you estimate it right or probably too pessimistic and get done ahead of time, but still the project is late in the end because they forgot about D, E, F, G, H and J. In the end you can fit D, E and maybe F in the time you have left because you got A, B, C done quicker than estimated but G, H and J are still missing.
- swimfar 9y ago
  I'm not in the software industry so this sounds really odd to me. Don't you guys write proposals to go along with the quote that detail exactly what is in the scope of work? Do you not have a contractual statement of work? If they come back and say, "oh, we forgot to say we also need D", then the response should be, "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal?" Or, if you're under budget and you're charging hourly rates instead of a fixed cost, you might even say you can probably add it without going over budget. PS: I just realized that you're probably talking about internal "clients" so there's no contract or even payment. But I think the same general idea applies. When they bring up extra features, you just say that it's going to take additional time. edit 2: I guess this doesn't actually help with getting the project done on time. The initial time estimate is still going to be off for the reasons you mentioned. So this comment isn't really an argument against anything you wrote.
  - DougWebb 9y ago
    That's funny. No, for most developers who are asked to provide an estimate, the analogy is more like this: PM: I want a bridge. When can we start using it? Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry? PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.
dizzystar 9y ago
As a contractor, I'm always asked for an estimate. The client is worried not about the time, but the thought I'll milk the clock, so an estimate ends up being a flat rate. The best way is to overshoot the time and offer the flat rate. If they bite, I can treble my usual rate, if they come back with a hard negation, I take that as an indicator that they will be difficult to work with. It's a a tough balance.
- user5994461 9y ago
  Don't forget the budget. All clients wants a number so they can evaluate whether they actually have the money to pay for it and whether the project is worthwhile. Noone wants to engage in a 6 months contract thinking it only takes 1. By the way, watch out when changing from daily rate to project. Legally, you have to deliver the project when you bill for a project, so you are forced to make a contract with well defined project scope to cover your ass. It's quite a lot of (billable) hassle.
  - dizzystar 9y ago
    I'm sure to get everything in writing. Interesting you bring that up though. I had a client through a contracting company. After the project was done, they said they actually asked for something more, which was never even discussed. I ended up partly unpaid even though I was clearly correct. The law works when the money is worth chasing.
    - user5994461 9y ago
      Your story is a school case, unfortunately. The law is never in your favor as a single man or small shop. It's too expensive to go to court, then determining what should have been done or not done as per the contract is a lengthy and uncertain proceeding. Clients who wanna pay per project basically want to move the risk over to you. They should pay a premium. Write a solid contract and increase the fees/duration. Most should give up when you start increasing the quote just to establish the contract, it's easier to start a POC and see what could be achieved.
thsowers 9y ago
When possible, I give three numbers. A best case scenario, the nominal scenario and the worse case scenario. Software Development is full of hidden pitfalls and I've found this can keep development and management teams both on the same page when unforeseen obstacles arise
bluetwo 9y ago
"Fixed scope, fixed price. Flexible scope, flexible price."
ufmace 9y ago
How to treat estimates is hugely dependent on the political situation at your company. Things such as, exactly what is your role, the role of the person asking, your relationship and their expectations, what will they use the information for? That plus the technical side of how many unknowns are involved in doing this thing, and how long it has taken to resolve similar types of unknown in the past. Maybe the most important thing to remember is to beware of keeping your old behavior with regard to estimating things when there's a sudden change in the management structure. You may go from someone who understands development and knows how to interpret and present a good-faith estimate from developers to higher ups, to someone who just presents your estimates up the chain verbatim. And that shift may not be obvious to the developer until the fallout from a bad estimate gets blamed on you.
- rangersanger 9y ago
  This. This is one of the reasons I left my last PM job. I was being told to spend less time with the team and more time on the road with clients. I don't know what the right ratio is, but I do know that my rapport with the team and deep familiarity with the stories/tasks led to pretty solid estimates. Also knowing the patterns of the dev lead helped a lot, he was a chronic underestimater so I'd do my best to push him to consider things like coordination, legacy, etc. Personality of the estimator plays a huge part and the voltile/stable essay was a great shortcut for understanding this. A voltile will hit the estimate or beat it. It'll be cowboy all day long and god help the company if it needs to be maintained. I've had a few dev leads like this. They'll take the tricky bits and do it alone. At night. On the weekend. Half asleep. Then, there is the stable. They'll never hit their original estimate. The most egregious won't get beyond the proof of concept without some serious prodding. When the project is done, it's meticulous, but we rarely get to that point because of the daily 6 hour long discussions about naming...
  - valuearb 9y ago
    PM = Project manager, or PM = Product Manager? If it's Project Manager, that's crazy.
bitL 9y ago
"The task of estimating how long a feature would take to implement is NP-C. Give me a quantum computer and come back in 4B years for an answer."
klenwell 9y ago
My favorite recent story on estimates comes from a previous company. (I've written about them before. There are reasons I am not working for them any more.) Before I was unceremoniously shown the door, we had been discussing a rewrite of our main customer-facing website. It was basically a bank website, but for a bank that only served a few hundred clients internal to the company. The most recent version had been written a few years ago in a Python web framework that was now defunct. This time we were going to do it right using Rails. We had been talking about a 6-8 month timeframe for release of the minimal viable version once the dev team got started. We had been talking about getting started for about 3-4 months while we got sidetracked with other spot fires, upgrades, and all the other workaday delays. The team used Agile Scrum, mostly in the ways you aren't supposed to use it (meandering voluntary standups that some developers would attend at their whim, perfunctory retrospectives in which process issues were swept under the rug, systematic disregard for the definition of done and best practices, an unhealthy focus on burndown charts). There was no special business urgency behind the upgrade as far as I knew other than the old application was getting long in the tooth and looked a bit out-of-date. It was still floating beneath the surface of the backlog when I was finally walked from the building. A year or so later I got together for lunch with a couple friends still with the company including a project manager from the old team. I asked her how the big bank site rewrite was going. "Oh, it's about where it was when you were still working there. Except now it's urgent." She was not happy. The banking unit had signed up some new customers who were outside the bank and the dev team's boss said executives were eager to integrate them into the new online system. So he asked my friend, as product owner, to give him an estimate on when the new site would be ready. My friend told him she'd get back to him on it. She logged into their project management system, filtered out all the non-essential user stories for the project, added up the sizing on the essential ones that were left, and then formed an estimate based on the team's average velocity over the last few sprints. Then, just to be safe, she removed a couple more stories that probably were essential to the MVP, added up the new total, bumped up the team's velocity a few points on the reasonable premise that they were inveterate slackers, and updated her final estimate. She then met with her boss to present her results. She premised her estimate by outlining her methodology. She reminded him that the last version had taken over a year to complete. Then she dropped the number: "Six months." "Too long. We need to have it ready in three months." My friend looked at him slack-jawed. "I don't think that's possible." She started to review her methodology. He stopped her. "It is possible." "How?" "Double the team's velocity." This guy had been the one who had championed scrum to the company. He had hired the consulting firm that ran the three-day scrum on-site workshop that had introduced the principles of Agile Scrum in detail to the company. He had attended the workshop. We all had. Twice! My friend found a new job and left the company within a month.
rs999gti 9y ago
Map out all the requirements and tasks. Put an estimation to each. Sum up the hours. Multiply the estimate by 2.5. Even then 2.5 isn't enough of a hours multiplier. A lot of these enterprise systems have traps and tricks other developers and analysts have put in. :( :/
- aryehof 9y ago
  > Map out all the requirements and tasks. Arguably problematic even when the project is relatively trivial. Try it for a new "Air Traffic Control System" or new "Bank Customer Lending Management System".
cel1ne 9y ago
Apart from the social issues there‘s a nice cognitive corrective described in „heretics guide to best practises“. 1. optionally divide your project in arbitrary smaller tasks 2. for each subtask pick a range (min and max estimate) so that you‘re sure the actual time lies in the range 90% of the time. 3. imagine the following decision: you can draw one out of 9 black and 1 red marble. If you pick the red you get 10.000$. That‘s a chance of 90%. OR: you can choose your estimate and get 10.000$ if it‘s correct. If you think about this decision and rather pick the marble-game, then your estimate is too narrow and most likely not correct. If you pick your estimate over the marble game, it‘s too wide, because you‘re more than 90% sure about it. Adjust your estimate until the decision doesn‘t matter anymore and both the game and your estimate seem like equal chances to you. 4. my own addendum for people who are afraid of asking too much: double the result to take the stress of yourself.
Animats 9y ago
The key to estimation is good historical data. If you have data on how long previous things took, estimation can be reasonably accurate.
- klenwell 9y ago
  This is the technique I've adopted. Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find similar stories (or, if you're just getting started, requests of comparable scope) you worked on in the past and use those as a reference. What happened instead: team quickly ended up equating story points to some unit of time (e.g. 1 pt = 1 day to complete). Then, for a new story, play planning poker where each developer makes estimates based on rose-tinted projections of how long they imagined it would take them to finish the job if they were working on it alone without major distractions or unanticipated complications. After everyone reveals their estimate, argue pointlessly with each other for a random amount of time. Then, once the scrum master has caught up on all the latest notifications on his or her phone, either cave to the opinion of the most belligerent member of the team or average the results. After we got burned a few times, we added a "shit happens" cushion while still following the same basic procedure. I'd be surprised if that team didn't continue to use the same protocol to this day while gradually ballooning their cushion to the point their estimates coincided with the "double the number, shift to the next time unit" rule. Daniel Kahneman provides a good lesson on the difference between these kind of expert-driven (for various definitions of the word "expert") estimates and the sort of historical data-based approach you suggest in Thinking Fast and Slow. It's excerpted here: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/daniel-kahneman-beware-the-inside-view https://www.mckinsey.com/business-functions/strategy-and-cor...
  - valuearb 9y ago
    Story points should never be equate to any unit of time. No wonder people argued. And fire the scrum master because they weren't running an effective agile process. Switch the team to a Kanban board, and prioritize, don't estimate, work. Time estimates are a fools errand, even with historical data. Historical data won't tell you if this task is really similar to that old task, or if fast dev will work on it or whether the slow dev will, or how many meetings devs will be pulled into, or who will need PTO, etc, etc.
jwatte 9y ago
In "debugging the development process," the author recommends the method of "make a quick estimate, then give a range between that and 5x that. Suggest that the estimate can be made narrower only with significant additional scheduled work." I like it, because it's true, it works, and it deals with the inherent uncertainty of software development by letting those who ask decide how much they want to pay for how much certainty.
mratzloff 9y ago
In my many years of estimating, the ONLY thing I have found to work consistently is to meticulously break work into a series of tasks taking no longer than a few hours. Real time, not points. Don't estimate in a meeting. Let people go back to their desks to research and document the issue. Give them time. It takes longer, but it yields more accurate estimates. Have the team meet up again afterward and let everyone discuss the estimates and how they arrived at each piece. Let the team come to a group consensus about each estimate. By breaking it out into a series of small tasks, you also have a daily schedule and a daily benchmark to work against: [x] X (2 hours est., 2 hours actual) [x] Y (3 hours, 5 hours actual) [ ] Z (1 hour) Now you have a daily update: "I went 2 hours over on Y yesterday and didn't get to Z, but I stayed a little later to get Y finished. I'm at least 1 hour behind schedule, but I think I can make it up today and tomorrow." This makes you super dependable to management and keeps you on task. Super dependable means you make them look good--which means you're first to get the choice assignments, first to get a bonus or raise, first to get a promotion. Managers know that schedules occasionally slip; what they want is to know as early as humanly possible so they can make a decision about the project.
- valuearb 9y ago
  This is why Agile is such an effective development process. By not using time estimates it removes almost the entire planning overhead and lets devs spend far more of their time actually developing.
  - mratzloff 9y ago
    It really doesn't take that much time to create a detailed estimate (and then pad it for contingencies). Ultimately the entire rest of the world operates on the basis of real time, not sliding-scale points.
    - valuearb 9y ago
      It never takes long to put time estimates together that will lead to disastrous project management decisions. The rest of the world benefits far more from faster and more effective product development than it does schedule estimations.
psyc 9y ago
I tell them whatever I think they’ll think is reasonable. What actually happens won’t bear much resemblance to whatever number I give, and it won’t matter to whether we ship.
z3t4 9y ago
The requirements will be a rocket ship to Mars, while all they need is a bus to the picknick. You argue that they really only need a bus, but then they go with a competitor, that delivers a rocket that almost makes it to the stratosphere. Then they take taxis to the picknick. So you promise the Mars mission, but with the estimate of the bus trip.
watwut 9y ago
Be glad. Worst is when managers estimate themselves. Be pessimistic, don't count happy flow only. Count also meetings and other organizational slowdowns into estimation. It can be anything between 30% to 200% of needed time depending on what politics on your company is. Break it down, and guess shortest time possible, longset time possible and them most likely time for each task. Then do (min+max+4×likely)/6 and sum them. The result will look intuitively too long, but resist temptation to shorten it. Then resist pressure to make it smaller. If they want it faster, keep calm and ask them whether take out this or that feature. The only way to make it faster is by cutting features.
- valuearb 9y ago
  No time estimate should ever be made by anyone not responsible for implementing it.
sillysaurus3 9y ago
One thing I could use help with: How do you respond when someone asks you for a monetary estimate? I was approached by someone who wanted to hire me as a freelancer, but the requirements were quite vague. He wanted a general idea of how much I billed daily, but I really didn't know how to answer it. $300? $600? What's high enough to hook them, but not too high to push them away? How do you factor in risk? What if they don't like what I deliver? This seems related to time estimation, but different enough to ask.
- ReverseCold 9y ago
  That's a good question for them to ask, usually you'll go for a lower rate. If possible, try to get them to make an offer, or try to dodge the question (gracefully, do not attempt if not skilled at that). Another thing that sometimes works is giving a really high number, but then offering a "deal". YMMV.
  - sillysaurus3 9y ago
    I did manage to dodge the question, but now I'm not sure what the next step is. Do you have any advice? Last time I tried this, my rate was high enough that they balked. I'd like to avoid that, but still charge enough to make it worthwhile. I thought it'd go like this: Start at double my highest rate, then wait for them to counteroffer. Commence negotiation. But last time they just walked.
    - sokoloff 9y ago
      Assuming you're not hurting for work, you want them to wince a little when they hear your rate. Regular on site visits and full-time, local work? $1000/day minimum in the high cost of living area I'm in (Boston area). If they straight out walk at that, you dodged a bullet. Bidding too high and losing the work is way, way better than bidding too low and getting it!
    - rorykoehler 9y ago
      Ask them what their budget is. If they don't know or refuse to say, offer to help them calculate the market opportunity or efficiency savings (depending on nature of project) in terms of revenue. Use this to get a budget out of them and then let them know what they can expect for that budget.
valuearb 9y ago
The only correct answer for a programming estimate is, "No one knows". Seriously, tomorrow morning I'm going to be in a long planning meeting where I'm going to be asked for time estimates. And this time i'm going to refuse to give any. I've spent a fair bit of time preparing my boss, my bosses boss, and people on my team for this moment, by explaining good Agile development doesn't use time estimates. I'm going to insist that I and my fellow developers will point problems using planning poker, but the points won't correspond to any fixed time amounts.
uptownfunk 9y ago
If you’re having trouble figuring out an estimate then try the following exercise. Imagine a pointy haired project manager who knows little to nothing about code say “Code refactoring, let’s see that’s what, one or two days?” Immediately you will have outraged yourself and you will start figuring out the right answer. And once you have, double it. If they question you and counter your estimate give a very uncomfortable “uhhh....” followed by “it’s much more complicated than it seems, I don’t think that’s possible”.
konschubert 9y ago
I don't know. I just know that it's childish to refuse to make an estimate at all. It's part of being a professional to be able to give some kind of ballpark estimate.
- valuearb 9y ago
  It's unprofessional to give time estimates since you know they can't ever be accurate and it's poor software development practice to rely on them. Its your job to educate your boss and your team about this.
nevinera 9y ago
Tell them that it'll take an hour or so of effort, but they'll have their estimate by tomorrow morning. Then spend some real time documenting the more and less certain areas of change, the likely risks, and the unlikely-but-very-costly risks. The estimate will be dramatically more accurate, but more importantly, they will stop asking for it when it doesn't matter.
- nevinera 9y ago
  Frequently, the right answer is actually "I won't know until I spike on it - that will take a couple of days".
valuearb 9y ago
I once worked in an organization that only allowed engineers to make estimates once, at the beginning of typically 6 month projects. No elaborate research was allowed, all estimates were given off the cuff in a single 1 hour team planning session. In the 6 years I was there they shipped around 40 different software products, without once shipping late or a buggy product, and won dozens of industry awards. It's not time estimations. Its how you manage your process.
- sumedh 9y ago
  > 40 different software products What kind of software products?
  - valuearb 9y ago
    Graphics and desktop publishing utilities. And I mistyped, it wasn't 40 different products, it was 40 different major releases, only about 8 different products. Though hundreds of minor releases counting Japanese, Spanish, French and German versions, and point releases.
plasma 9y ago
Estimates are important. If you can’t answer right away, “I’ll get back to you” after having some time to think about what’s needed. Then just keep that person up to date on timeline progress and it other work that’s been requested impacts that estimate.
valuearb 9y ago
If asked for an accurate schedule for a large project, offer management two options. 1) Two months spent writing complete product requirements documentation, while engineers research and estimate all tasks and sub-tasks. 2) We start right now with the minimal documentation we have, using priorities Marketing has given us and work with Marketing to flesh out the details for every component as we build it. In case 1), you get a schedule in two months. The schedule won't be accurate because it won't be able to anticipate everything. Most likely it won't be able to anticipate how product requirements will change during our lengthy development, and they most certainly will change given that Marketing isn't going to stop talking to customers or thinking of new ideas. But you'll have a schedule. In case 2) I'll guarantee the project will be finished faster and be a better product. You don't get an accurate schedule either, but you also don't lie to yourself that the one you have is accurate.
aryehof 9y ago
1a. Make (but don't immediately communicate) a best guess based on initially determinable requirements (functional and non-functional), which includes a large amount of contingency. [It is ideal to understand the problem with "use cases" and "stories" is that they are a poor building block for estimation and development because they inevitably require further and further decomposition.] 1b. Formally (in writing) present the estimate, together with the known requirements upon which it is based. 1c. Include in writing that changes in requirements (and undiscovered requirements) w ill affect the estimate. 1d. Document and immediately communicate in writing all new and changed requirements. When your boss's boss (inevitably) asks him what the problem is with this project taking so long, and he responds to him that you the developer (or team) "keeps finding problems and more work to do", you can at least rely on a written record of the project's changing scope.
segmondy 9y ago
If you're asked for an estimate. Give an estimate. Part of your job is giving an estimate. Find out how to break the job down into something you have done before, and give an estimate. Will you see a doctor who can't estimate how long a surgery will take? Will you take a cab or a flight that refuses to give you an estimate? Will you take a job that can't give you an estimate of what the salary range will be. They will figure it out when they pay you. Come on, cut the rubbish folks. This is why we get no respect from non tech folks. Everything doesn't revolve around tech. Businesses have decisions to make based on time product gets to market. They have decisions to make based on cost of product. Estimates allows them to make such decisions. Learning to give estimate is one of the best skills you could ever have as a developer.
- wetpaws 9y ago
  You must be new here

253 points by lainon 9y ago

Also: Is it an estimate or a deadline? Most of the time, you will give an estimate, and the manager will turn the sum of your estimates into a deadline. Don't fall into this trap.

redler 9y ago
I try to consistently use the word "target" to head off the ambiguous semantics around time estimates versus "deadlines". It's a little thing, but it can be psychologically easier if one explicitly controls the project language to allow "we need to revise our target" than to be implicitly seen as "not meeting a deadline".

didibus 9y ago

One thing I've been unable to ever see adopted is a true bottom up planning strategy, where the time to delivery is estimated from historical data. Say last X project took Y time, similar Z project will thus take Y time. And from there, the business plans timeline and delivery dates. The reason for this is that in practice I've found estimates are an indirect way to define scope. You need to ballpark the minimal viable product in a range from under a month, a month to 3 months, 3 to 6, 6 to 1 year, over a year. After that, its just about downscoping all the "good to haves" based on if there's time left from the desired deadline or not. As long as you delivered the "must have" in your timeframe it should be good.

valuearb 9y ago
The more work that is put into a planning process, the later the product will ship.

wolfgke 9y ago

It is common programmer folklore to apply the 80/20 rule to estimate the time required to implement a feature - and I don't mean the Pareto principle, but "Do a worst case estimate, add 80 hours and multiply this sum by 20". :-)

huffpopo 9y ago

Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At most companies estimates are about control, expectation management, and blame distribution and not about information discovery. Most people really suck at expectation management, much more than they suck at estimating work.

honor_roller64 9y ago
Triple it and then you have some headroom for when they halve it.
- justherefortart 9y ago
  I make my best guess and quadruple it. That tends to be the most accurate I get. I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else. So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.
  - ghaff 9y ago
    An engineering manager I used to work with would drive me crazy. He had this "methodology" he referred to as a 90% schedule but it was a 90% confidence schedule only in the sense of no one ever getting sick for a couple of days, tests not failing, no hardware being defective, etc. etc. It won't come as a surprise that this schedule was basically never met.
- patrickmay 9y ago
  Double it and go to the next higher units. 4 hours? That's 8 days.
- paulie_a 9y ago
  Exactly. Never give a be range either. The lowest number is now your estimate.

glenjamin 9y ago

The best approach to this I have found is to ask why. What decision are you trying to make using this estimate? Understanding context helps you to understand what sort of estimate is needed - or whether an estimate is needed at all.

Rabei 9y ago
The question is to know how much it costs, sometimes they also want to know if they'll meet some external deadline.
- convolvatron 9y ago
  I think what the GP is getting at is that an estimate in absence of a context is meaningless. The organization may just be trying to get a handle on the rough scope of a job to make strategic decisions. They may also be in the middle of a discussion with a customer about delivering a feature. The best thing for both the company and yourself is to try to be as high bandwidth as possible and discuss all the potential risks and tradeoffs. Find out what the real goals are so you can optimize a solution to provide for them. Many managers and customers get stuck early on with a particular approach, but if you apply some creative engineering you can come up with a solution which is easier, or folds in with some other goal you were already working on, leverages existing functionality etc. its on you to express it in terms they can understand from their own position: risk, cost, headcount, schedule, dropping existing features. if your organization doesn't want to engage in that kind of semantically meaningful discussion, or comes back and says 'I know you said 3 months, but get in don't in 2 weeks' then you need to start managing upward and looking for a new job. or you can just overestimate, and enjoy your free 2 hour lunches for as long as the money lasts.

vermooten 9y ago

I don't do estimates any more but I use forecasting. Like the weather, it's an idea of what might happen given what we know now. I once laughed in a job interview when the interviewer said that they expect 'accurate estimates'.

valuearb 9y ago
I would have responded "Then your dev process is broken".

WisNorCan 9y ago

There is a difference between establishing a deadline and estimating relative effort and complexity. The former is problematic. The latter is important and should be done and then revised continuously. The process of building software includes discussing what has the best impact to effort ratio. Both are estimates and will not come out as expected. The logical response to managers that expect you to always hit deadlines is to inflate estimates enough that you will.

rrggrr 9y ago

My flow adapted for this question: 1. Why do you need the estimate? Is it to get budget approval, or because you're trying to meet an approved budget? If they don't have budget approval then I'm going to charge them something to gather requirements and deliver an estimate. No budget approval = low on priority list. 2. We charge a blended rate of $xxx per hour. If you have a detailed requirements list I can tell you if we can do this within your budget. If they don't have a detailed requirements list then I'm going to charge them to provide one. After I have the requirements list completed I'm asking for their budget. 3. Don't want to pay for a requirements list? I understand. Its okay. Something like this typically costs (low bid), but that will likely change if the requirements are different then my assumptions.

jlj 9y ago
Could you elaborate on #3? Do you walk away at that point? A last attempt to show the value of good requirements and get them back to #2, else they are premtively "fired" as a client? Going to hold onto these. Good phrasing/ideas.
- rrggrr 9y ago
  In enterprise software, at least the companies I know, they will underbid and return to the well many times for increases. They will blame this on poorly scoped requirements, for which they were not responsible. They will be right, and they count on this for much profit. If you quote virtuously, you will be a victim of your client and competitors who scope/quote less virtiously.

wruza 9y ago

At our company we didn’t estimate entire projects, but separated tasks until it was 3-5 hours piece of work that everyone agreed “it’s realistic, I can do it”. The big time then simply summed up with 30% buffer for delays. Since our customers mostly paid for hours, it was also a good base price builder. Big projects can suffer from this because little architecture is involved (and we worked on already existing systems). Otoh, I’ve seen no big local project that wasn’t an architectural mess once it hit a deadline hard. It is better to not have one than to have a set of rules that you must obey, while other parts of system don’t even care of or contradict these. Personally I don’t believe this “I’ll get back to you with an estimate” thing. It is just first iteration where you go relax and try to formulate at least 5-10 questions that you think you should ask foremost to start building an estimate. If you come back with an answer instead, then it is still wrong, maybe even worse than random, since you estimated a different thing. For us, estimates and requirements always moved, as they were functions of delays and business priorities that change unpredictably. I didn’t like to deliver the entirety on a deadline because my job was to support that for years, not throw a bill at them and run, as all integrators did. Maybe, maybe these SE-users are speaking about coding phase, when all “business analysis” was done perfectly. But ime it is you coder who collects all the knowledge, because no one can. Or it is you who is non-coding analyst who must estimate, because non-analytic coders don’t have a clue what a big picture is.

twic 9y ago

"Six to eight weeks" https://meta.stackexchange.com/a/19514/154820 https://meta.stackexchange.com/a/19514/154820

amelius 9y ago

Tell them there's a probability density function associated with the result. This allows you to get away with any outcome :)

christopherslee 9y ago

engineers hate giving estimates for a variety of reasons that i'm not going to get into here. most modern agile organizations don't value spending time on getting accurate estimates, but some kind of best-faith estimate is still valuable for a lot of reasons. for medium to large size projects i like to give a confidence score to my estimate to give a sense of how much unknown there currently is. for example: we think we can get this ticket done in 5 days, but there's a 50% chance it will take two weeks (because of complications in X, Y, and Z). or the other way, my estimate is 3 days, but if this one thing works out that we're looking into, there's a chance we can finish it in 1 day. what people are generally asking for with estimates is sizing and complexity, so providing some additional information helps.

GordonS 9y ago
I like to do something similar - I break down what I see are the risks, add a risk factor accordingly, then provide the estimate as a range. For example, the risk factor my be 50%, so I'll say the cost will be between £100k and £150k (for example). I find this really helps to focus the customer stakeholders who can control some of those risks.
newfoundglory 9y ago
Some devs seem to have actual phobias of estimates. My team was asked if we can deliver features x or x+ some time next year. (IMO as the dev who knows both the code and x best, we can deliver x in 2018 easily and x+ maybe). In our discussions about it, one guy would only say you can't predict the future, and another guy argued we should say either of them would take two years so that we could have time to rebuild the app from scratch while we delivered them. It's a web app.
- christopherslee 9y ago
  tl;dr - we engineers are bad at estimation because we're too optimistic, and then we don't want to be accountable to the estimate given based on limited information. i think we have phobias for estimates because of management repercussions that only happen when you miss an estimated delivery date, or for organizations that put external dates based on a best-case aggressive engineering estimate. then when the engineering team misses the date, there's a retro (when retros should happen for both good and bad sprints.) i've never been clear why more organizations don't soft launch features or products, and then pick a marketing/external announcement date.

stesch 9y ago

Pro tip: Don't laugh. The boss once asked me for an estimate and I laughed. He said that wasn't funny and I said that he started it! On the other hand: Do it. Laugh. Laugh in his face when you are called to help on a project that isn't ready after 1 year and started without you. When they show some wire-frames and ask you how long it takes without telling you about the actual technology used for the project. Summer 2015 I was uninvited from a project meeting. My coworker was planning the project and discussed it a bit with me. He wasn't the one who decided that I shouldn't take part. Summer/Fall 2016 and the project isn't going anywhere. I'm invited to help. I do my best, besides the other projects. January 2017 and my coworker is gone. He gave his 3 months (+ x days) notice and told me December 2016. Shortly after it I gave my 4 1/2 months notice. The new deadline for the project was May 2017. They launched November 2017. "Cool story, bro. What was it? Some revolutionary VR or AR application? AI supported super gadget? Brainwave reader and interpreter?" … It was the company's own website.

pjzedalis 9y ago
I have been in a similar situation. Any project like this one can often go off the rails if the right decision makers are not involved. This is not necessarily the fault of the project leader as it can be unintuitive in bureaucracies.
- redler 9y ago
  Corporate websites, in particular, can be pathological cases. The closer to completion, the more "stakeholders" come out of the woodwork.
lkrubner 9y ago
I've a similar story. May of 2015: hired at startup that wants to use Natural Language Processing so salespeople can send text messages directly to their CRM (Salesforce, PipeDrive, etc). Very excited about the project. The app's initial UI design is a traditional one, with NLP helping to smooth the basic task. The full app would take about a year to build but we all agreed we could have an MVP by August. August of 2015: without consulting anyone on the tech team, the Board Of Directors decides the app should get rid of all standard UI elements: no forms, no buttons, no links, no drop down menus. Instead, the interface should be a pure chat app. This makes the project much more ambitious, which I was very excited about, but which I felt would delay the project 2 or 3 months. Nobody was happy with my estimate. September of 2015: the CEO was able to show a demo to the Board Of Directors. The demo was an illusion, as we had no error handling, and it only worked for some carefully planned examples, but I thought it was a good sign that we could show the Board that we were making progress. Unknown to me, the Board then asked the CEO for real feedback from real customers at the next meeting, a month later, in October. There was no possible way for us to finish the product, and find customers, and get feedback, all in a month, but the CEO was a bit of a coward, so he promised the Board we would do this. October of 2015: obviously we did not have customer feedback by the next meeting of the Board. At this point the Board decides we have missed our schedule and they begin to panic. We are slowed by the fact that our "NLP expert" is inexperienced. Myself and our iPhone programmer tell management that we need to fire the current NLP guy and hire someone with real experience. Management initially agrees but then later changes its mind, for reasons unstated. November of 2015: we get a basic demo working, and it has enough error checking that we can show it to potential customers, and not be entirely embarrassed. But the stress of the previous month has wrecked relationships inside the company, people are shouting at each other constantly. At this point I step away from the project, but I remain on friendly terms with the guy who is doing the iPhone programming. January of 2016: company gets two trial customers, but these customers won't pay for the product. The NLP engine is improving, but at glacial speed, as the "NLP expert" is at the beginning of his career. He was a nice person, and I can believe he will eventually become a good programmer, but it didn't make sense that a company that wanted to move fast also remained so loyal to a guy who could not do what was needed. An established company could/should afford to have an apprenticeship program, but a fast moving startup can not offer an apprenticeship to someone working on a core technology. April of 2016: the iPhone guy again asks management to find a new NLP expert, someone who can move the company forward. Management reacts by listing every bug ever discovered in the iPhone app, as a way of telling the iPhone guy to shut up. May of 2016: the iPhone programmer quits and gets a job elsewhere. June of 2016: the company is almost out of money, so it cuts back on spending, reduces the team. summer and autumn of 2016: without much staff, the company crawls along at a glacial pace Early 2017: the company gets more funding, begins moving forward again. Summer of 2017: the company now has a few trial customers, but they are paying trial rates, which is to say, almost nothing. The company is not anywhere close to the breakeven point. The company continues to burn money without making much progress. There are clearly some fundamental leadership issues that should be addressed, and one of those are the ways that estimates and budgets are created. Also, the company would be in much better shape if the leadership listened to feedback from the tech team. I wrote about all of this in detail here: https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/0998997617/ https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...

falcolas 9y ago

My PM has a great way for dealing with engineer estimates: increment both the number and the unit. 1 hour becomes 2 days. 4 days becomes 5 weeks. And so forth. I'm actually somewhat decent at estimating well defined work, so it actually annoys him when one day is one day; but I appreciate his work when some odd stumbling block (usually political; my estimating skills crash and burn when it involves working with humans) comes up and the time doubles or triples the estimate.

eps 9y ago
It's a very old PM joke. The original version is "double fhe number, shift to the next time unit."
- falcolas 9y ago
  The best jokes have their roots in reality. Of course, when the joke works in reality, is it still a joke?
  - eximius 9y ago
    Some of the best jokes are funny because they're true.
- whamlastxmas 9y ago
  A one year project is now a two decade project
  - hrktb 9y ago
    Seems about right. A year is an eternity anyway, you shouldn’t start a project with nothing coming out of it before a year, that’s suicide on so many plans.
    - user5994461 9y ago
      A software project that takes a year will costs a fortune (salaries are expensive). It will probably have to be maintained and running for the next decades to give enough returns to be worthwhile. So, 1 year is the time the first interns team will work on it, 10 year is the duration before the project is retired. Looks like both estimates were right.

thomk 9y ago

Bill your clients for estimates and still give ranges. The more they want to dial in those ranges, the more billable time you spend estimating. "How long will it take to estimate" is a question you should be able to answer because you will control the deliverable in this case. Also, if you spend time with them asking questions and helping them discover the complexity of their request, they will soon see the benefit of this process. Alternatively what I'll do is point out that their request is simply incomplete and I can help them create a better request, which I will then estimate (it's all still billable though).

redler 9y ago
It's critical to position yourself (or your company) to be able to bill for discovery (a separate project, or at least a day-rate engagement). You're a consultant working with the client to figure out what the project actually is. Amazingly, the client often doesn't really know, as can become apparent during that first gathering around a whiteboard. And if they don't know, you're well on your way to a "now that I see what you've done, it's not really what we had in mind" moment.
- rboyd 9y ago
  Great point. Also worthwhile is to consider the overall likelihood of success for projects you take on (and what it implies for future work, quality of life while working with the client, etc). I wasted a lot of time early in my career on projects that I knew were doomed just because someone agreed to pay my rate.

rogerbinns 9y ago

I give an estimate with an error margin, that is usually larger. eg something like "that will take about 3 weeks, plus or minus 2 months". The plus or minus bit reflects the uncertainty in requirements, things that could change etc. Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant. That is why I include the "minus" bit covering this scenario where a solution is already there.

arkades 9y ago
> I give an estimate with an error margin, that is usually larger. eg something like "that will take about 3 weeks, plus or minus 2 months" I can’t tell if you’re being serious. How do people respond to such a non-estimate?
- LambdaComplex 9y ago
  3 weeks minus 2 months...I'd probably ask if that means it might be done already
  - rogerbinns 9y ago
    Yes, that was precisely the point with "Often it is the case the goal can already be achieved with existing functionality, but may not be as direct or elegant".
- rogerbinns 9y ago
  I am very serious. My clients respond very well because it helps them plan better. The problem with a traditional one number estimate is you don't see the error bars so they don't know how to treat "3 weeks". My approach also helps start a discussion about how to reduce the size of the plus/minus bit, such as reducing scope, breaking into multiple pieces etc. And the minus bit coming to negative time works well too. It becomes a decision about using what is already there even if not perfectly suited versus doing the new work, and how much of it to do.

aorloff 9y ago

Explain that the way to do estimates is to have a process that starts by breaking down the work into the components of the design, estimating each component, and adding it up, with small padding to each granular component. The more granular the breakdown, the more accurate the estimate. For a single top-line complete project guess (which is what you are being asked) you should use a large pad, as comments below say, double and shift. If you can afford the time to do the breakdown, you will get a closer and more realistic number, and have some of the project planning work done to boot.

deleted 9y ago

[deleted]

gavanwoolery 9y ago

At my company we use simple analysis on previous estimates and adjust future estimates based on past errors. We are usually about 70 to 100 percent accurate using this method. However, projects are usually not more than 7 days of work in my case.

GenSpecialist 9y ago
This is something I wish I saw more talked about: how to get better at estimates. I wish more people dedicated time to reviewing their projection & mindset at the time, then look at the task timeline, then write down what caused it to go off schedule. Sometimes it's an environment change. Are these consistent? Can they be modeled statistically? Often, it's an inaccurate belief in the work to be done. Was it lack of requirements, that had to be expanded? Etc. When I work in development, I spent up to 20% of my time on "overhead" tasks. These are of the estimate review type, not meetings. It's something a great manager will do without wasting his team's time, but as an independent, I spend a lot of time doing it myself, and it's amazing how much it helps to dedicate time and write things down.
valuearb 9y ago
Why on earth would you waste a single minute doing any planning for a 1 week project?

sheeshkebab 9y ago

Oddly enough t-shirt sized estimates work well. get a sense whether task is S, M, L, or XL from developers etc... and then multiply it by whatever factor you think S-XL should be in hours/days. people can't seem to provide time-base estimates - but generally have a good sense of a complexity of a problem.

redler 9y ago
A similar trick to help crystallize thinking about the project is to ask whether it's on the order of hours, days, weeks, or months. This mitigates the fear of speaking a number and having it be enshrined as a guarantee, while connecting the rumination process to the experience of past projects in all their underestimated splendor.
- wiredfool 9y ago
  I like this approach, especially for getting estimates out of trades that don't like doing estimates before they tear apart your clutch. "Is this a hundreds of dollars or thousands of dollars problem" can work wonders.

xahrepap 9y ago

I like to say, "my gut says X days. But I'll have to get back to you." I think there's a lot value in having the conversation with the PM or manager or whomever in the moment. And being non-committal is frustrating for the other parties.

clooless 9y ago
That "gut estimate" converts to a concrete deadline in your PMs mind before you put a period at the end of your sentence.
- xahrepap 9y ago
  Not in my experience. I think it's about managing expectations. You just have to be clear about what you mean with that individual. If that PM takes it to mean that then you need to find another way to communicate your message. I think what I intend to say with that can be, "I don't know how long it takes and it'll take more planning to figure it out, but I'm willing to participate in this conversation so that we can continue to effectively plan in the current context." If the current context is "concrete" then you probably don't want to give a number. If the conversation is (and this was my assumption before) "here's a feature we want done but we're trying to figure out it's priority and feasibility" then giving a gut check adds value. You just need to be clear in your messaging. And if someone uses a gut check number against you "but you said X days!" Then you need to call them on it and make sure you explained the discrepancy.

kesor 9y ago

Just keep in mind that estimation != promise. Make estimations to help you plan your time, but never commit these to management who turns them into promises.

mikmoila 9y ago

Don't forget psychological aspects: http://www.cs.toronto.edu/~sme/papers/2005/ESEC-FSE-05-Aranda.pdf http://www.cs.toronto.edu/~sme/papers/2005/ESEC-FSE-05-Arand...

k__ 9y ago

The problem with estimates is mostly requirement analysis. When people say they need feature A, B and C and ask when I will have it done, I split it up in tasks that take below a day, estimate these tasks and add 50% for safety. This works in most cases. But often the reason why projects won't finish on time is, because people don't know what they want. They ask for A, B, C, you estimate it right or probably too pessimistic and get done ahead of time, but still the project is late in the end because they forgot about D, E, F, G, H and J. In the end you can fit D, E and maybe F in the time you have left because you got A, B, C done quicker than estimated but G, H and J are still missing.

swimfar 9y ago
I'm not in the software industry so this sounds really odd to me. Don't you guys write proposals to go along with the quote that detail exactly what is in the scope of work? Do you not have a contractual statement of work? If they come back and say, "oh, we forgot to say we also need D", then the response should be, "that's no problem, we estimate it will take an additional X hours or dollars to implement that. Would you like us to update the proposal?" Or, if you're under budget and you're charging hourly rates instead of a fixed cost, you might even say you can probably add it without going over budget. PS: I just realized that you're probably talking about internal "clients" so there's no contract or even payment. But I think the same general idea applies. When they bring up extra features, you just say that it's going to take additional time. edit 2: I guess this doesn't actually help with getting the project done on time. The initial time estimate is still going to be off for the reasons you mentioned. So this comment isn't really an argument against anything you wrote.
- DougWebb 9y ago
  That's funny. No, for most developers who are asked to provide an estimate, the analogy is more like this: PM: I want a bridge. When can we start using it? Eng: Uh, ok, where is the bridge? What's is going over? What kind of traffic will it carry? PM: I want a bridge. Why are you being difficult? Tell me right now when we can start using it! I've got to go promise my boss that you committed to getting it done by then! Oh, btw, it needs to be done next week.

dizzystar 9y ago

As a contractor, I'm always asked for an estimate. The client is worried not about the time, but the thought I'll milk the clock, so an estimate ends up being a flat rate. The best way is to overshoot the time and offer the flat rate. If they bite, I can treble my usual rate, if they come back with a hard negation, I take that as an indicator that they will be difficult to work with. It's a a tough balance.

user5994461 9y ago
Don't forget the budget. All clients wants a number so they can evaluate whether they actually have the money to pay for it and whether the project is worthwhile. Noone wants to engage in a 6 months contract thinking it only takes 1. By the way, watch out when changing from daily rate to project. Legally, you have to deliver the project when you bill for a project, so you are forced to make a contract with well defined project scope to cover your ass. It's quite a lot of (billable) hassle.
- dizzystar 9y ago
  I'm sure to get everything in writing. Interesting you bring that up though. I had a client through a contracting company. After the project was done, they said they actually asked for something more, which was never even discussed. I ended up partly unpaid even though I was clearly correct. The law works when the money is worth chasing.
  - user5994461 9y ago
    Your story is a school case, unfortunately. The law is never in your favor as a single man or small shop. It's too expensive to go to court, then determining what should have been done or not done as per the contract is a lengthy and uncertain proceeding. Clients who wanna pay per project basically want to move the risk over to you. They should pay a premium. Write a solid contract and increase the fees/duration. Most should give up when you start increasing the quote just to establish the contract, it's easier to start a POC and see what could be achieved.

thsowers 9y ago

When possible, I give three numbers. A best case scenario, the nominal scenario and the worse case scenario. Software Development is full of hidden pitfalls and I've found this can keep development and management teams both on the same page when unforeseen obstacles arise

bluetwo 9y ago

"Fixed scope, fixed price. Flexible scope, flexible price."

ufmace 9y ago

How to treat estimates is hugely dependent on the political situation at your company. Things such as, exactly what is your role, the role of the person asking, your relationship and their expectations, what will they use the information for? That plus the technical side of how many unknowns are involved in doing this thing, and how long it has taken to resolve similar types of unknown in the past. Maybe the most important thing to remember is to beware of keeping your old behavior with regard to estimating things when there's a sudden change in the management structure. You may go from someone who understands development and knows how to interpret and present a good-faith estimate from developers to higher ups, to someone who just presents your estimates up the chain verbatim. And that shift may not be obvious to the developer until the fallout from a bad estimate gets blamed on you.

rangersanger 9y ago
This. This is one of the reasons I left my last PM job. I was being told to spend less time with the team and more time on the road with clients. I don't know what the right ratio is, but I do know that my rapport with the team and deep familiarity with the stories/tasks led to pretty solid estimates. Also knowing the patterns of the dev lead helped a lot, he was a chronic underestimater so I'd do my best to push him to consider things like coordination, legacy, etc. Personality of the estimator plays a huge part and the voltile/stable essay was a great shortcut for understanding this. A voltile will hit the estimate or beat it. It'll be cowboy all day long and god help the company if it needs to be maintained. I've had a few dev leads like this. They'll take the tricky bits and do it alone. At night. On the weekend. Half asleep. Then, there is the stable. They'll never hit their original estimate. The most egregious won't get beyond the proof of concept without some serious prodding. When the project is done, it's meticulous, but we rarely get to that point because of the daily 6 hour long discussions about naming...
- valuearb 9y ago
  PM = Project manager, or PM = Product Manager? If it's Project Manager, that's crazy.

bitL 9y ago

"The task of estimating how long a feature would take to implement is NP-C. Give me a quantum computer and come back in 4B years for an answer."

klenwell 9y ago

My favorite recent story on estimates comes from a previous company. (I've written about them before. There are reasons I am not working for them any more.) Before I was unceremoniously shown the door, we had been discussing a rewrite of our main customer-facing website. It was basically a bank website, but for a bank that only served a few hundred clients internal to the company. The most recent version had been written a few years ago in a Python web framework that was now defunct. This time we were going to do it right using Rails. We had been talking about a 6-8 month timeframe for release of the minimal viable version once the dev team got started. We had been talking about getting started for about 3-4 months while we got sidetracked with other spot fires, upgrades, and all the other workaday delays. The team used Agile Scrum, mostly in the ways you aren't supposed to use it (meandering voluntary standups that some developers would attend at their whim, perfunctory retrospectives in which process issues were swept under the rug, systematic disregard for the definition of done and best practices, an unhealthy focus on burndown charts). There was no special business urgency behind the upgrade as far as I knew other than the old application was getting long in the tooth and looked a bit out-of-date. It was still floating beneath the surface of the backlog when I was finally walked from the building. A year or so later I got together for lunch with a couple friends still with the company including a project manager from the old team. I asked her how the big bank site rewrite was going. "Oh, it's about where it was when you were still working there. Except now it's urgent." She was not happy. The banking unit had signed up some new customers who were outside the bank and the dev team's boss said executives were eager to integrate them into the new online system. So he asked my friend, as product owner, to give him an estimate on when the new site would be ready. My friend told him she'd get back to him on it. She logged into their project management system, filtered out all the non-essential user stories for the project, added up the sizing on the essential ones that were left, and then formed an estimate based on the team's average velocity over the last few sprints. Then, just to be safe, she removed a couple more stories that probably were essential to the MVP, added up the new total, bumped up the team's velocity a few points on the reasonable premise that they were inveterate slackers, and updated her final estimate. She then met with her boss to present her results. She premised her estimate by outlining her methodology. She reminded him that the last version had taken over a year to complete. Then she dropped the number: "Six months." "Too long. We need to have it ready in three months." My friend looked at him slack-jawed. "I don't think that's possible." She started to review her methodology. He stopped her. "It is possible." "How?" "Double the team's velocity." This guy had been the one who had championed scrum to the company. He had hired the consulting firm that ran the three-day scrum on-site workshop that had introduced the principles of Agile Scrum in detail to the company. He had attended the workshop. We all had. Twice! My friend found a new job and left the company within a month.

rs999gti 9y ago

Map out all the requirements and tasks. Put an estimation to each. Sum up the hours. Multiply the estimate by 2.5. Even then 2.5 isn't enough of a hours multiplier. A lot of these enterprise systems have traps and tricks other developers and analysts have put in. :( :/

aryehof 9y ago
> Map out all the requirements and tasks. Arguably problematic even when the project is relatively trivial. Try it for a new "Air Traffic Control System" or new "Bank Customer Lending Management System".

cel1ne 9y ago

Apart from the social issues there‘s a nice cognitive corrective described in „heretics guide to best practises“. 1. optionally divide your project in arbitrary smaller tasks 2. for each subtask pick a range (min and max estimate) so that you‘re sure the actual time lies in the range 90% of the time. 3. imagine the following decision: you can draw one out of 9 black and 1 red marble. If you pick the red you get 10.000$. That‘s a chance of 90%. OR: you can choose your estimate and get 10.000$ if it‘s correct. If you think about this decision and rather pick the marble-game, then your estimate is too narrow and most likely not correct. If you pick your estimate over the marble game, it‘s too wide, because you‘re more than 90% sure about it. Adjust your estimate until the decision doesn‘t matter anymore and both the game and your estimate seem like equal chances to you. 4. my own addendum for people who are afraid of asking too much: double the result to take the stress of yourself.

Animats 9y ago

The key to estimation is good historical data. If you have data on how long previous things took, estimation can be reasonably accurate.

klenwell 9y ago
This is the technique I've adopted. Interestingly when I was first introduced to scrum years ago, this is how my team was taught to estimate stories. Find similar stories (or, if you're just getting started, requests of comparable scope) you worked on in the past and use those as a reference. What happened instead: team quickly ended up equating story points to some unit of time (e.g. 1 pt = 1 day to complete). Then, for a new story, play planning poker where each developer makes estimates based on rose-tinted projections of how long they imagined it would take them to finish the job if they were working on it alone without major distractions or unanticipated complications. After everyone reveals their estimate, argue pointlessly with each other for a random amount of time. Then, once the scrum master has caught up on all the latest notifications on his or her phone, either cave to the opinion of the most belligerent member of the team or average the results. After we got burned a few times, we added a "shit happens" cushion while still following the same basic procedure. I'd be surprised if that team didn't continue to use the same protocol to this day while gradually ballooning their cushion to the point their estimates coincided with the "double the number, shift to the next time unit" rule. Daniel Kahneman provides a good lesson on the difference between these kind of expert-driven (for various definitions of the word "expert") estimates and the sort of historical data-based approach you suggest in Thinking Fast and Slow. It's excerpted here: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/daniel-kahneman-beware-the-inside-view https://www.mckinsey.com/business-functions/strategy-and-cor...
- valuearb 9y ago
  Story points should never be equate to any unit of time. No wonder people argued. And fire the scrum master because they weren't running an effective agile process. Switch the team to a Kanban board, and prioritize, don't estimate, work. Time estimates are a fools errand, even with historical data. Historical data won't tell you if this task is really similar to that old task, or if fast dev will work on it or whether the slow dev will, or how many meetings devs will be pulled into, or who will need PTO, etc, etc.

jwatte 9y ago

In "debugging the development process," the author recommends the method of "make a quick estimate, then give a range between that and 5x that. Suggest that the estimate can be made narrower only with significant additional scheduled work." I like it, because it's true, it works, and it deals with the inherent uncertainty of software development by letting those who ask decide how much they want to pay for how much certainty.

mratzloff 9y ago

In my many years of estimating, the ONLY thing I have found to work consistently is to meticulously break work into a series of tasks taking no longer than a few hours. Real time, not points. Don't estimate in a meeting. Let people go back to their desks to research and document the issue. Give them time. It takes longer, but it yields more accurate estimates. Have the team meet up again afterward and let everyone discuss the estimates and how they arrived at each piece. Let the team come to a group consensus about each estimate. By breaking it out into a series of small tasks, you also have a daily schedule and a daily benchmark to work against: [x] X (2 hours est., 2 hours actual) [x] Y (3 hours, 5 hours actual) [ ] Z (1 hour) Now you have a daily update: "I went 2 hours over on Y yesterday and didn't get to Z, but I stayed a little later to get Y finished. I'm at least 1 hour behind schedule, but I think I can make it up today and tomorrow." This makes you super dependable to management and keeps you on task. Super dependable means you make them look good--which means you're first to get the choice assignments, first to get a bonus or raise, first to get a promotion. Managers know that schedules occasionally slip; what they want is to know as early as humanly possible so they can make a decision about the project.

valuearb 9y ago
This is why Agile is such an effective development process. By not using time estimates it removes almost the entire planning overhead and lets devs spend far more of their time actually developing.
- mratzloff 9y ago
  It really doesn't take that much time to create a detailed estimate (and then pad it for contingencies). Ultimately the entire rest of the world operates on the basis of real time, not sliding-scale points.
  - valuearb 9y ago
    It never takes long to put time estimates together that will lead to disastrous project management decisions. The rest of the world benefits far more from faster and more effective product development than it does schedule estimations.

psyc 9y ago

I tell them whatever I think they’ll think is reasonable. What actually happens won’t bear much resemblance to whatever number I give, and it won’t matter to whether we ship.

z3t4 9y ago

The requirements will be a rocket ship to Mars, while all they need is a bus to the picknick. You argue that they really only need a bus, but then they go with a competitor, that delivers a rocket that almost makes it to the stratosphere. Then they take taxis to the picknick. So you promise the Mars mission, but with the estimate of the bus trip.

watwut 9y ago

Be glad. Worst is when managers estimate themselves. Be pessimistic, don't count happy flow only. Count also meetings and other organizational slowdowns into estimation. It can be anything between 30% to 200% of needed time depending on what politics on your company is. Break it down, and guess shortest time possible, longset time possible and them most likely time for each task. Then do (min+max+4×likely)/6 and sum them. The result will look intuitively too long, but resist temptation to shorten it. Then resist pressure to make it smaller. If they want it faster, keep calm and ask them whether take out this or that feature. The only way to make it faster is by cutting features.

valuearb 9y ago
No time estimate should ever be made by anyone not responsible for implementing it.

sillysaurus3 9y ago

One thing I could use help with: How do you respond when someone asks you for a monetary estimate? I was approached by someone who wanted to hire me as a freelancer, but the requirements were quite vague. He wanted a general idea of how much I billed daily, but I really didn't know how to answer it. $300? $600? What's high enough to hook them, but not too high to push them away? How do you factor in risk? What if they don't like what I deliver? This seems related to time estimation, but different enough to ask.

ReverseCold 9y ago
That's a good question for them to ask, usually you'll go for a lower rate. If possible, try to get them to make an offer, or try to dodge the question (gracefully, do not attempt if not skilled at that). Another thing that sometimes works is giving a really high number, but then offering a "deal". YMMV.
- sillysaurus3 9y ago
  I did manage to dodge the question, but now I'm not sure what the next step is. Do you have any advice? Last time I tried this, my rate was high enough that they balked. I'd like to avoid that, but still charge enough to make it worthwhile. I thought it'd go like this: Start at double my highest rate, then wait for them to counteroffer. Commence negotiation. But last time they just walked.
  - sokoloff 9y ago
    Assuming you're not hurting for work, you want them to wince a little when they hear your rate. Regular on site visits and full-time, local work? $1000/day minimum in the high cost of living area I'm in (Boston area). If they straight out walk at that, you dodged a bullet. Bidding too high and losing the work is way, way better than bidding too low and getting it!
  - rorykoehler 9y ago
    Ask them what their budget is. If they don't know or refuse to say, offer to help them calculate the market opportunity or efficiency savings (depending on nature of project) in terms of revenue. Use this to get a budget out of them and then let them know what they can expect for that budget.

valuearb 9y ago

The only correct answer for a programming estimate is, "No one knows". Seriously, tomorrow morning I'm going to be in a long planning meeting where I'm going to be asked for time estimates. And this time i'm going to refuse to give any. I've spent a fair bit of time preparing my boss, my bosses boss, and people on my team for this moment, by explaining good Agile development doesn't use time estimates. I'm going to insist that I and my fellow developers will point problems using planning poker, but the points won't correspond to any fixed time amounts.

uptownfunk 9y ago

If you’re having trouble figuring out an estimate then try the following exercise. Imagine a pointy haired project manager who knows little to nothing about code say “Code refactoring, let’s see that’s what, one or two days?” Immediately you will have outraged yourself and you will start figuring out the right answer. And once you have, double it. If they question you and counter your estimate give a very uncomfortable “uhhh....” followed by “it’s much more complicated than it seems, I don’t think that’s possible”.

konschubert 9y ago

I don't know. I just know that it's childish to refuse to make an estimate at all. It's part of being a professional to be able to give some kind of ballpark estimate.

valuearb 9y ago
It's unprofessional to give time estimates since you know they can't ever be accurate and it's poor software development practice to rely on them. Its your job to educate your boss and your team about this.

nevinera 9y ago

Tell them that it'll take an hour or so of effort, but they'll have their estimate by tomorrow morning. Then spend some real time documenting the more and less certain areas of change, the likely risks, and the unlikely-but-very-costly risks. The estimate will be dramatically more accurate, but more importantly, they will stop asking for it when it doesn't matter.

nevinera 9y ago
Frequently, the right answer is actually "I won't know until I spike on it - that will take a couple of days".

valuearb 9y ago

I once worked in an organization that only allowed engineers to make estimates once, at the beginning of typically 6 month projects. No elaborate research was allowed, all estimates were given off the cuff in a single 1 hour team planning session. In the 6 years I was there they shipped around 40 different software products, without once shipping late or a buggy product, and won dozens of industry awards. It's not time estimations. Its how you manage your process.

sumedh 9y ago
> 40 different software products What kind of software products?
- valuearb 9y ago
  Graphics and desktop publishing utilities. And I mistyped, it wasn't 40 different products, it was 40 different major releases, only about 8 different products. Though hundreds of minor releases counting Japanese, Spanish, French and German versions, and point releases.

plasma 9y ago

Estimates are important. If you can’t answer right away, “I’ll get back to you” after having some time to think about what’s needed. Then just keep that person up to date on timeline progress and it other work that’s been requested impacts that estimate.

valuearb 9y ago

If asked for an accurate schedule for a large project, offer management two options. 1) Two months spent writing complete product requirements documentation, while engineers research and estimate all tasks and sub-tasks. 2) We start right now with the minimal documentation we have, using priorities Marketing has given us and work with Marketing to flesh out the details for every component as we build it. In case 1), you get a schedule in two months. The schedule won't be accurate because it won't be able to anticipate everything. Most likely it won't be able to anticipate how product requirements will change during our lengthy development, and they most certainly will change given that Marketing isn't going to stop talking to customers or thinking of new ideas. But you'll have a schedule. In case 2) I'll guarantee the project will be finished faster and be a better product. You don't get an accurate schedule either, but you also don't lie to yourself that the one you have is accurate.

aryehof 9y ago

1a. Make (but don't immediately communicate) a best guess based on initially determinable requirements (functional and non-functional), which includes a large amount of contingency. [It is ideal to understand the problem with "use cases" and "stories" is that they are a poor building block for estimation and development because they inevitably require further and further decomposition.] 1b. Formally (in writing) present the estimate, together with the known requirements upon which it is based. 1c. Include in writing that changes in requirements (and undiscovered requirements) w ill affect the estimate. 1d. Document and immediately communicate in writing all new and changed requirements. When your boss's boss (inevitably) asks him what the problem is with this project taking so long, and he responds to him that you the developer (or team) "keeps finding problems and more work to do", you can at least rely on a written record of the project's changing scope.

segmondy 9y ago

If you're asked for an estimate. Give an estimate. Part of your job is giving an estimate. Find out how to break the job down into something you have done before, and give an estimate. Will you see a doctor who can't estimate how long a surgery will take? Will you take a cab or a flight that refuses to give you an estimate? Will you take a job that can't give you an estimate of what the salary range will be. They will figure it out when they pay you. Come on, cut the rubbish folks. This is why we get no respect from non tech folks. Everything doesn't revolve around tech. Businesses have decisions to make based on time product gets to market. They have decisions to make based on cost of product. Estimates allows them to make such decisions. Learning to give estimate is one of the best skills you could ever have as a developer.

wetpaws 9y ago
You must be new here