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

Re: Customer doesn't trust our estimates

Expand Messages
  • Bill Wake
    ... That s good. ... If you re done, you re done. It took me a long time to get sensitive to when I was over-tired, and even longer to get myself to stop when
    Message 1 of 50 , Apr 1, 2003
    • 0 Attachment
      > "rodriguez_jose48" <rodriguez_jose48@y...>
      > > "Bill Wake" <william.wake@a...>

      > Yes. Today estimates are closer to the true cost. Estimating the XP
      > way is a major improvement.
      That's good.

      > > Two things for working too slowly:
      > > 1. *Are* you going too slow? Look hard at yourselves [...]
      > We are working as much as we can. We are tired after 5 or 6
      > hours, so we cannot continue.

      If you're done, you're done. It took me a long time to get sensitive
      to when I was over-tired, and even longer to get myself to stop when
      I hit that point.

      (It's not unheard of for people to worry about whether suppliers or
      managees are working hard enough; I'm not sure it often helps much.
      There's a mode where people would rather see you do 6 hours work and
      4 hours of rearranging deck chairs, then just a good 6 hours work.)

      > > >
      > > > 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).
      > >
      > > Again, this comes out as a fear response. We don't want to hide
      > > things.
      > >
      > > If you've got a little history, you can say "this story's about
      as
      > > big as that one we did, with that estimate". I'm not so sure the
      > > ideal days/weeks thing is always so helpful; you might try just
      > > points without explicitly relating them to time.
      > >
      >
      > Yes. This might be a solution. However some of us (programmers) are
      > more comfortable thinking in ideal time than comparing with another
      > story.

      Well, I'd say do whatever way helps you best converge on accurate
      estimates. And I'd also suggest letting go of the fear that your
      customer will find out what you're really up to. The goal is "one
      team"; excluding the customer from the deliberations won't help that.

      (And that you feel you have to hide your work level really feels off
      to me.)


      You are trying to reverse a vicious circle into a virtuous cycle.

      You'll be better off the more your customer is in the room, working
      things through with you. (I'll return to another point I made - if
      it's too expensive, you can brainstorm cheaper options.) You want to
      know each others' "pain".

      The old way, with poor estimates: customer gives you stories, you
      give poor estimates, people go off and work, the deadline approaches
      and you have to slip, customer complains about the slip.

      The current way, with good estimates: customer proposes a story, you
      go off by yourselves & estimate, customer complains about the
      estimate, you implement as estimated.

      The way to move toward: customer proposes, you work together through
      the story and the estimate, brainstorming ways to make it cheaper if
      it costs too much, you implement as estimated.

      The later ways have more and better feedback, and the last one tries
      to align your goals rather than set up a win-lose situation.


      -- Bill Wake William.Wake@... www.xp123.com
    • 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.

        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.