Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Re: Customer doesn't trust our estimates

Expand Messages
  • Ron Jeffries
    ... Perhaps it was. We need to be sure that we are working enough. ... She would be wiser to ask if you are working smarter. Are you automating tasks that are
    Message 1 of 50 , Apr 1, 2003
    • 0 Attachment
      On Tuesday, April 1, 2003, at 2:03:37 AM, rodriguez_jose48 wrote:

      > We have nedded more time in the past. She thinks that was due to the
      > fact that we didn't work enough.

      Perhaps it was. We need to be sure that we are working enough.

      > Now we give more acurate estimates, but she thinks we are making them
      > too big. She wants us to work harder.

      She would be wiser to ask if you are working smarter. Are you automating
      tasks that are often done manually. Are you spending time debugging when
      less time testing would have been more effective. We need to be sure we are
      working smart enough, and hard enough.

      >> Yes, we experience a similar amount of "effective coding time". What
      >> would happen if you told her?

      > Only 5-6 hours a day??? You should work 8 hours! You are wasting my
      > money!

      "Teams all over the world are reporting that 5 to 6 hours effective coding
      time is the best that they can achieve. Here is a graph of the past few
      weeks showing what else we do during each day. Perhaps you can help us
      eliminate or reduce these activities but they seem important to us, to you,
      or to our management.

      "As always, if you can find a team that is somehow able to operate without
      planning, without meetings, without design sessions, you should definitely
      hire them."

      She: "You should work more hours."

      You [truthfully, which means you have to measure it]: "We have measured our
      velocity and defect production at various points. Here's the graph. As you
      can see, we make the best progress over the course of the project in this
      range here. That's why we work in this range. If you would like us to work
      outside that range, you should expect less net production due to mistakes,
      rework, and defects."

      It's never easy. Just keep measuring progress, estimating better and
      better, and telling the truth.

      Ron Jeffries
      Analysis kills spontaneity.
      The grain once ground into flour germinates no more. -- Henri Amiel
    • davechaplin
      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
      • 0 Attachment
        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.


        --- In extremeprogramming@yahoogroups.com, "rodriguez_jose48"
        <rodriguez_jose48@y...> wrote:
        > Now, after we've managed to have some separation of
        > 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
        > 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
        > I've seen on this list that others have a similar period of
        > 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
        > (we are estimating in ideal days and weeks).
        > Any ideas?
        > Jose.
      Your message has been successfully submitted and would be delivered to recipients shortly.