Sorry, an error occurred while loading the content.

## Re: Customer doesn't trust our estimates

Expand Messages
• ... your ... gets 30 ... but have ... So multiply by 7. Or randomly add or subtract a point. Or don t multiply at all; just call them points. I have an
Message 1 of 50 , Apr 1, 2003
--- In extremeprogramming@yahoogroups.com, "rodriguez_jose48"
<rodriguez_jose48@y...> wrote:
> --- In extremeprogramming@yahoogroups.com, "banshee858"
> <cnett858@s...> wrote:
> > Perhaps you need to multiply
> > every estiamte by ten in order to get the idea of days out of
your
> > customer's head? So instead of 3 ideal days, your customer
gets 30
> > points! I have heard that suggestion bounced around here,
but have
> > not used it. Might work for you.
> >
>
> Yes, I've thought about it. But having only 10, 20 and 30 point
> stories is not different from having 1, 2 and 3 point stories.
>
> Jose

So multiply by 7. Or randomly add or subtract a point. Or don't
multiply at all; just call them points.

I have an unproven hypothesis: thinking in terms of ideal days is
misleading for everybody, not just the customer. I think that
some developers keep chasing that ideal when they estimate. It's
kind of like the joke about doubling your estimates so that
they'll be 50% of the real value.

Forget about how much ideal programming time you can get done
In particular, it won't lead to getting more done during a day.
That can only happen in two ways: by improving the code and
practices so that you can produce more functionality with less
effort, and by removing things that take away from productive
time. Ideal time has nothing to do with the former. Ideal time
won't identify those things in the latter.

I think ideal time is assumed by some to better that points
because is more "real". It's not. The hint is that word "ideal".
That implies "not real". What's worse than not knowing something?
Knowing something that isn't true!

This soapbox is a bit rickety, so I better step down now. ;->

Kiel Hodges
SelfSo Software
• Is your customer technical? If so, then ask them to show you how they would do it quicker. Admit that you don t know. You know yourself that you are working
Message 50 of 50 , Apr 9, 2003
Is your customer technical? If so, then ask them to show you how they
would do it quicker. Admit that you don't know. You know yourself
that you are working very fast using XP, and that the quality
investments you are making will pay off. You can gamble on that. Make
sure your estimates accurate though, since no-one likes a deadline
that isn't hit. Under promise /commit, and over deliver.

Don't tell her you are coding 6 hours a day regardless. Tell her you
are coding 8, then make sure you only code spikes and R&D stuff in
the other 2 hours. Personally, we stop touching production code after
about 4pm. Our brains are a bit dead. Then we work on previously
marked TODO's/STUB's in the code that are low brain activities to fix.

Regarding the problems with times estimates. Give a range if you are
unsure. e.g. between 5 and 15 days. Tell her you need to do some R&D
for 2 days to get an accurate estimate. If she takes the lower one
that is her problem and you have a project management problem you
need to solve. Openly refuse to commit to deadlines unless you are
sure of hitting them. I suspect you had project overuns in the past
because someone else other than the developers was promising
something that couldn't be delivered. Seen that before. It was solved
by the particular project manager being marched out the building by
security. That solved it!

Hope that helps.

Dave.

--- In extremeprogramming@yahoogroups.com, "rodriguez_jose48"
<rodriguez_jose48@y...> wrote:
> Now, after we've managed to have some separation of
responsibilities
> between programmers and Customer, our main problem is that the
> customer does not trust our estimates.
>
> She thinks we are giving her too big estimates, and that we are
> working too slowly. She is right in thinking like this because in
the
> past this project didn't went so well, and schedule overruns were
> a 'normal' thing.
>
> What can we do to solve this problem?
>
> This has a couple of bad consequences over the process.
>
> For example we cannot tell her we are programming only 5-6
hours/day.
> I've seen on this list that others have a similar period of
effective
> coding each day, so I believe it is a normal thing (anyway we are
> tired after 5-6 hours of effective coding).
>
> Another problem is that we fear to have the Customer with us during
> the planning. We fear that we will not be able to give an accurate
> estimate in a short time (planning a story shouldn't take long, I
> guess) and if we give a shorter estimate, she will not agree to
> change it in the future.
>
> Besides, during the planning game, we, the programmers, have to be
> careful, not to tell anything about the mapping real time/ideal
time
> (we are estimating in ideal days and weeks).
>
> Any ideas?
>
> Jose.
Your message has been successfully submitted and would be delivered to recipients shortly.