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

Re: [XP] Customer relation

Expand Messages
  • J. B. Rainsberger
    ... I have passed this on to the team. I hope they ll remain aware of it, and I wish you best of luck. -- J. B. (Joe) Rainsberger Diaspar Software Services
    Message 1 of 14 , Mar 1, 2005
    • 0 Attachment
      Gary Brown wrote:
      > J. B. Rainsberger wrote:

      > One of the teams I am currently coaching has chronically
      > under-delivered. We are rewriting an existing system. The team members
      > are well aware of the good things and bad about the current system. The
      > are motivated to keep the good and eliminate the bad. As I observe them
      > working through each story, I see that they are frequently willing to
      > add a little bit extra. While this might seem like a good thing, it
      > causes us to slow down. I have asked them to write a ToDo list on the
      > back of each story card when it is estimated, then draw a line under the
      > last item. When the story is implemented, add any additional tasks
      > below the line. I am hoping that we will begin to understand whether we
      > are missing required tasks, which causes us to under-estimate, or we are
      > adding tasks that could be deferred, which causes us to spend more time
      > than we had planned. Time will tell ...

      I have passed this on to the team. I hope they'll remain aware of it,
      and I wish you best of luck.
      --
      J. B. (Joe) Rainsberger
      Diaspar Software Services
      http://www.diasparsoftware.com
      Author, JUnit Recipes: Practical Methods for Programmer Testing
    • J. B. Rainsberger
      ... Please tell me more about the risks you see with splitting stories this way that outweigh the risks of never delivering an iteration on time. ... I don t
      Message 2 of 14 , Mar 1, 2005
      • 0 Attachment
        Michael Dubakov wrote:
        >
        >>>I'm going to try asking the customers to split stories into smaller
        >>>chunks, so as to reduce the average estimation error per story.
        >>>This should help the programmers get a clue about how fast they can
        >>>go. I think it'll work quite well. Perhaps they'll even deliver one
        >>>good iteration this time around. I can't wait.
        >
        > I don't think this is a good idea to split user stories just because
        > of the possible better estimates.

        Please tell me more about the risks you see with splitting stories this
        way that outweigh the risks of never delivering an iteration on time.

        > You could split user story on tasks, estimate each task and define
        > user story's effort as a sum of the tasks' effort. This may solve the
        > problem.

        I don't think I understand the difference between this and splitting the
        stories, except that with the tasks, I miss the opportunity to ask the
        customer, "If we just did /this/ bit, would that be all right?" and get
        the joyous answer, "Sure!"
        --
        J. B. (Joe) Rainsberger
        Diaspar Software Services
        http://www.diasparsoftware.com
        Author, JUnit Recipes: Practical Methods for Programmer Testing
      • Michael Dubakov
        ... Yes, I mean exactly that. User Story should represent chunks of functionality for sure. ... we started splitting any stories that look bigger. It helped.
        Message 3 of 14 , Mar 1, 2005
        • 0 Attachment
          >If you're saying, "if you have trouble estimating a story, try
          > estimating its tasks,"

          Yes, I mean exactly that. User Story should represent "chunks of
          functionality" for sure.

          > I split big stories too. In one case, we looked back and realized,
          > "stories estimated at more than 2 points never come in on time" so
          we started splitting any stories that look bigger. It helped.

          If you could split story and both new stories will have business
          value, that's ok.

          Michael
          http://www.targetprocess.com
          XP Planning & Bug Tracking software


          --- In extremeprogramming@yahoogroups.com, William Wake
          <william.wake@g...> wrote:
          > On Mon, 28 Feb 2005 16:06:42 -0000, Michael Dubakov
          <firefalcon@t...> wrote:
          > > I don't think this is a good idea to split user stories just because
          > > of the possible better estimates.
          >
          > I split big stories too. In one case, we looked back and realized,
          > "stories estimated at more than 2 points never come in on time" so we
          > started splitting any stories that look bigger. It helped.
          >
          > > You could split user story on tasks, estimate each task and define
          > > user story's effort as a sum of the tasks' effort. This may solve the
          > > problem.
          >
          > If you're saying, "if you have trouble estimating a story, try
          > estimating its tasks," I'm good with that. But I wouldn't normally
          > split stories based on tasks - I want them to represent chunks of
          > functionality that users/customers can value.
          >
          > --
          > Bill Wake William.Wake@a... www.xp123.com
        Your message has been successfully submitted and would be delivered to recipients shortly.