
How to respond when you are asked for an estimate? - lainon
https://softwareengineering.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate
======
huffpopo
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.

~~~
MereInterest
Sounds a lot like the scene in Star Trek: The Next Generation, where Geordi La
Forge meets Scotty.

> Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain
> everything to you, but the Captain wants this spectrographic analysis done
> by 1300 hours.

> [La Forge goes back to work; Scotty follows slowly]

> Scotty: Do you mind a little advice? Starfleet captains are like children.
> They want everything right now and they want it their way. But the secret is
> to give them only what they need, not what they want.

> Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this
> analysis done in an hour.

> Scotty: How long will it really take?

> Lt. Commander Geordi La Forge: An hour!

> Scotty: Oh, you didn't tell him how long it would _really_ take, did ya?

> Lt. Commander Geordi La Forge: Well, of course I did.

> Scotty: Oh, laddie. You've got a lot to learn if you want people to think of
> you as a miracle worker.

~~~
thaumaturgy
I always hated that scene, because it fundamentally changed the character of
Mr. Scott from engineer to engineering manager. Which, he was, but that wasn't
what made his character so compelling to begin with.

LaForge was a competent engineering manager. The writers tended to focus more
on the character's people management skills (and, sometimes, terrible personal
relationship stuff). He kept things running smoothly. He was smart. You could
imagine a detailed maintenance work log for every system on the ship, and
there'd be no gaps in it ever since he took the position of chief engineer.

But while Scotty cared about his staff, it was the machinery that he knew
inside and out. He never needed to conjure up a hologram of the designer of
the warp engines, because he knew them as well as anyone else. His maintenance
logs would have gaps because he'd know which things actually needed regular
attention, and which ones were just bureaucratic nonsense. He didn't just
understand all of it on the technician level, but on the theoretical level
too, enabling him to pull off some unlikely saves.

He actually was a miracle worker and maybe one of the best fictional
representations of an engineer, and that one scene was written to make him
look a little more like a bureaucrat.

~~~
mjevans
I felt that it was more for comedy as well as helping to develop the
difference in character between the two.

LaForge is competent, he's also newer in his overall career. Scotty has been
around the block so many times he knows where every crack and seam is.

That was a moment where Scotty's wisdom was being handed down; it's OK to know
what it will take, but stuff happens, and there's also the potential to hand
tasks off to less senior staff that might not do it at perfect speed. Giving a
padded estimate gives you options and room for corrections if there are
issues.

------
stesch
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
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
Corporate websites, in particular, can be pathological cases. The closer to
completion, the more "stakeholders" come out of the woodwork.

------
ufmace
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
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
PM = Project manager, or PM = Product Manager?

If it's Project Manager, that's crazy.

~~~
rangersanger
Yes product- though we didn't have project management to speak of. So, both.

~~~
valuearb
Those are two widely different roles in terms of day to day responsibilities
and skill sets, which points to a very bad organizational structure.

~~~
rangersanger
Depends on the context. Also, it was a smaller organization, gotta make due.
We frequently delivered on time and on budget, so, I don't think we lost much
with that structure.

~~~
valuearb
I've worked in less than 10 person companies that split that role for a
reason, it leads to far more effective development and better products.

A project manager's key role is to save money on developers. It's a hugely
cost efficient role when done well.

A product manager's job is to ensure the product meets customer
needs/requirements. Having them do menial tasks to remove roadblocks for
developers is totally orthogonal to their most important tasks.

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

~~~
EpicEng
>4 days becomes 5 weeks

Are you being serious? That only works if the people consuming these estimates
don't have a clue and therefore can't call BS. This would get me aughed out of
my job.

~~~
RealityVoid
This also astounds me. I can't graps the art of these estimates. I suck at
estimating deliviery times, and I'm a pretty good engineer. But I either over-
estimate or under-estimate, I find it hard to be on point, there are always
unexpected side effects. And I'm known as a sort of miracle worker, when they
have something they can't solve, they come to me. But I HATE giving estimates.

If I were to estimate things as suggested in this thread, it seems to me
things would never get done. Ever. It simply boggles my mind people want and
will fudge estimates on this scale.

~~~
falcolas
Pretend, for a moment, that you're working on a one week project. You're
estimating that week based on the ability to use an open source project which
promises to take care of a large portion of the complexity for you. Also
pretend you're new enough to not realize the hollowness of that promise.

It's only three days in to the project that you realize there's a mismatch
between what you need and what the project provides. You start a conversation
with the project's lead developer; but they're only able to have half of any
given conversation in a day. How hard would it be to spend five days
researching the cause and severity of the mismatch while discussing solutions
with the remote developer?

There's 8 days.

You decide to write a patch for the open source project shepherd it through
the internal and external approval process, burning up another two weeks of
time.

18 days.

You finally get back and finish the original project, redoing a fair bit of
work to account for the changes your patch introduced.

23 days.

You're interrupted throughout this process several times by fires in
production that need to be fixed _RIGHT NOW_.

28 days.

Let's make the assumption your PM did their little trick, and slated 2 months
for this project. Despite your own estimate being off (through no ill-will by
anybody) by about 6x, your work is still completed before it's expected, and
the teams depending upon your work are happy as clams. Even if it had finished
in the original 5 days, everyone would be thrilled, and you'd get more work to
do.

From the PM's point of view, it's a win-win situation. From your point of
view, the worst you have to endure is a twinge of "don't you trust me?",
offset by the relief of not having to answer "why isn't it done yet" every day
from day 6 on.

~~~
RealityVoid
Ideally, from my point of view, estimations should be not over nor under-
estimated. They should be on point. Sure, on first glance, under-estimation
leads to worse outcomes than oversetimation. But it will still lead to
negative outcomes. Rational actors on the wrole chain will benefit and extract
the most utility when they are as correct as possible.

While your example showed how project implementation can creep up, I already
knew that and my problem is more my inability to give accurate estimates and
people's willingness to stretch their estimates by a lot. I KNOW some of you
will not agree with me, but I think that giving 4x as long estimates will lead
to developers spending more time on the actual implementation without
noticeable improvements in the delivery. I know my natural tendency is to do
so.

------
glenjamin
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
The question is to know how much it costs, sometimes they also want to know if
they'll meet some external deadline.

~~~
convolvatron
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.

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

~~~
k__
also, they don't want a bridge, they want something like a bridge, but maybe
mobile or cloud based.

~~~
gvb
More like they ask for a car ferry to cross the river but really want a
bridge.

If you are lucky, you will recognize from their "requirements" (often just a
verbal description) that they are describing the characteristics of a bridge
(e.g. continuous bidirectional flow), not a ferry.

More typically, after you have built the car ferry, they ask why it doesn't
implement continuous bidirectional flow despite never specifying that as a
requirement.

~~~
user5994461
I think that last description is more on point. People can usually describe
why they want something, if asked, instead what they want. It's not too
difficult to come up with a reasonable scope if either the dev or the manager
knows how to start and scope a project.

Usually they both suck. The manager will send an unclear email. The developer
will start developing right away. None have any idea what they are supposed to
do, why or when.

~~~
k__
Often the manager also expects the dev to start right away.

For managers the value of a developer is the solutions they build divided by
the amount of time and information they need to build it.

You have always the choice between delaying further or delivering something
they like as soon as possible, risking they don't like it.

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

------
vermooten
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
I would have responded "Then your dev process is broken".

------
wolfgke
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". :-)

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

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

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

~~~
newfoundglory
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
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.

~~~
newfoundglory
I am an engineer. That isn't what I was trying to say. My interpretation of
these conversations would be more like "we think managers are morons".

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

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

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

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

------
segmondy
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
You must be new here

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

------
sillysaurus3
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
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
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
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!

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

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

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

------
nevinera
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
Frequently, the right answer is actually "I won't know until I spike on it -
that will take a couple of days".

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

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

------
didibus
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
The more work that is put into a planning process, the later the product will
ship.

------
watwut
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
No time estimate should ever be made by anyone not responsible for
implementing it.

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

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

------
valuearb
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
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”.

------
twic
"Six to eight weeks"

[https://meta.stackexchange.com/a/19514/154820](https://meta.stackexchange.com/a/19514/154820)

------
rogerbinns
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
> 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
3 weeks minus 2 months...I'd probably ask if that means it might be done
already

~~~
rogerbinns
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".

------
valuearb
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
> 40 different software products

What kind of software products?

~~~
valuearb
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.

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

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

~~~
klenwell
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-
cor...](https://www.mckinsey.com/business-functions/strategy-and-corporate-
finance/our-insights/daniel-kahneman-beware-the-inside-view)

~~~
valuearb
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.

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

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

~~~
valuearb
I'm going to add burn-down charts to my list of bad Agile fails.

\- Using points as measures of time

\- Redefining "done" as something that's not really done

\- Trying to ship fixed feature sets ("your commitments!") within a sprint

\- Any type of time estimates.

\- Burndown charts

------
thsowers
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

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

------
xahrepap
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
That "gut estimate" converts to a concrete deadline in your PMs mind before
you put a period at the end of your sentence.

~~~
xahrepap
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.

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

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

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

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

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

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

