

Software development: dealing with awful estimates - Unosolo
http://programmers.stackexchange.com/questions/39449/dealing-with-awful-estimates/39461#39461

======
cromulent
I have a customer whose strictly-enforced process is:

    
    
      1. Estimate (based on one-sentence title of feature)
      2. Wait for approval
      3. Find out detailed requirements
      4. Design and document
      5. Implement and deploy
    

3,4, and 5 should be included in your original estimate.

If you try to do 3 first, you are _not following the process_. The process is
touted as "best practice 2.0".

~~~
matei
Unfortunately, there are many situations in which you get 3 after the initial
estimation, since 3 is a long process which usually can occur only after a
deal was made with the client. And in most(every) case, the client wants to
have a clear price before signing a deal. The price usually depends on the
number of man hours required for the project, so the estimate has to come
before step 3. It's a defective process, but difficult to correct.

~~~
cromulent
Sure, but in our case we have an ongoing deal. What happens is that quality
(think % of requirements met) varies to meet the estimate, and the customer
loses. They are trying to control budget, but the granularity is wrong.

It's actually fairly easy to correct, but then it wouldn't be "best practice
2.0".

~~~
gte910h
Sounds like this customer needs to work of a priority list. You get all the
features you could implement, and stick them in a list with rough estimates of
time (at like a small medium, large, very large type sizing). You then get
_the customer to reorder them_. Then, work from the top down. You can likely
predict a certainty line and a maybe line. Share these depending on customer
"maturity".

The same "don't get all the features done" thing you were suffering before
will happen with the client, however this time, they'll get the most important
ones done, and they'll understand "oh hey, giving a bit more time will get X
out the door".

And this can be done "outside the process" possibly slipping past the
consultants dicta as just "helping you out to figure out what's most important
to them".

~~~
cromulent
Thanks, but we have a high level of awareness of what could be done better,
and a high level of experience in doing it the right way. I'm not looking for
ideas here, I was just trying to illustrate that bureaucracies can win quite a
few rounds before you can wear them down with "I refuse to give an estimate
until I do due diligence" approaches.

------
gte910h
I do like that he puts forth the "don't agree to stupid" and "don't agree to
hurry unduly" positions.

I disagree with him on "Normally, the way it works, is that your estimate is
first scanned for odd looking or relatively large items. Hence be prepared to
defend anything with “non-standard” name. Also split larger tasks so that all
tasks have same order of magnitude, i.e. if most tasks take 2 days and one
single task is 10 days be prepared to get drilled."

I believe generally you should actually communicate the hard parts of the
project to people. You should actually communicate what about it is hard if
you have any ability to do so, and you should state alternative risk
management strategies you've turned down for what reasons if they ask about
them.

~~~
rix0r
Sure, but what I think he meant was: if one work item is very large, it should
be broken down to make sure there's no work hiding in there that got
overlooked.

------
StudyAnimal
This is one thing the agilists have gotten right.

Estimate the size of the problem in abstract units like story points, and do
it in small chunks.

