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

RE: [XP] prioritizing stories

Expand Messages
  • Bryan Dollery
    Ron Jeffries wrote ... Okay, I ve just re-read chapter-8 of Installed (BTW: I love the small chapters). I remember thinking when I first read it that this was
    Message 1 of 22 , Nov 1, 2001
    • 0 Attachment
      Ron Jeffries wrote
      > > Ron Jeffries wrote
      > >> Many organizations want a product shipped by some date. They want to
      > >> know what will be in it. A release plan lets you say with pretty good
      > >> accuracy what you are sure will be in, what might be in, and what will
      > >> almost certainly not be in.
      >
      > > I can see that a release plan would need to have in it a fairly accurate
      > > list of what will be released when. I can also see why this would be
      > > desirable. I just don't see how one would/could create it. Can you
      > > elucidate?
      >
      > Do the XP release plan process. For full details see "Installed" or
      > "Planning". Briefly, sit down with the customer and "all" the stories,
      > estimate them, lay them out in iterations.

      Okay, I've just re-read chapter-8 of Installed (BTW: I love the small
      chapters). I remember thinking when I first read it that this was odd. Now
      I know why (although I could easily be wrong), but more about that later.

      > >> In a product company this is especially important, as folks have to
      > >> line up advertising, tell customers what is coming, and so on.
      >
      > > Yeah, I get it. How do I get the information, and make it
      > accurate though.
      > > If I say feature X will be in, but our velocity is lower than I
      > suspected
      > > then X may not be in.
      >
      > That's why you break it into "will be there", "might be there", "won't
      > be there". And as you learn more, do the plan again and republish.
      > Good PR, addresses that honesty thing that derives from the Simplicity
      > value.

      I've always used best, worst, and likely case scenarios. I see them as being
      analogous.

      > > If I say feature Y will be in, and then, through
      > > discovery through out the project, the customer discovers that
      > Y isn't so
      > > important, or that it's actually feature Z that they wanted,
      > then Y won't be
      > > there.
      >
      > When the customer adds stories to the plan, she must either add time
      > (not recommended) or remove stories to restore the total. Either way,
      > she knows what she did. And republish the plan if anyone else needs to
      > know.

      So, we expect (and of course, embrace) change. Most of XP is predicated on
      doing the minimum amount of work that will _need_ reworking. So, we're
      deliberately doing work here that needs to be reworked. We're providing the
      customer with an accurate estimate, based upon the information we have
      available to us at the time.

      I hate it.

      I see the necessity, business planning, investment planning, setting
      expectations, etc. But I really don't like it. We're saying

      "to the best of our knowledge you'll get X on date Y",

      and at the same time saying,

      "but if things change we reserve the right to revise this"

      When we've already said that things _will_ change, and to plan otherwise is
      dumb.

      So, unless I've missed something, we've done something here that isn't
      entirely honest. Not a lie, because at the time the estimate is as accurate
      as available data will allow, but still a dishonesty because we _know_ that
      the estimate is wrong, perhaps only in a small way, but perhaps
      substantially, and we have no way of knowing which.

      Is this right?

      > But tell us how it's working for you, especially regarding people who
      > want to know what you're going to deliver by when?

      Oh, my clients want the information. The want a release plan. I create
      estimates based upon my experience of similar systems, as many metrics as I
      can gather, and my perceptions of their organisational adaptability. I then
      add the caveat that, based upon historical industry trends, I am probably
      wrong. I usually quote the Capers Jones figures that I've been posting here
      recently.

      So, I tell them what they want to hear, and then I give the probabilities
      that I'm wrong. I follow this with a worse, best, and likely case analysis
      of the estimates.

      I see that this isn't too different to what XP does, but then, I don't like
      what I do either. I'm just fishing for a better answer.

      Bryan
    • Ron Jeffries
      ... I just tell em that this isn t what will happen, but it is a lot like what will happen, and that we ll keep em informed. Tell what you know, and tell
      Message 2 of 22 , Nov 1, 2001
      • 0 Attachment
        Around Thursday, November 01, 2001, 11:12:10 AM, Bryan Dollery wrote:

        > So, unless I've missed something, we've done something here that isn't
        > entirely honest. Not a lie, because at the time the estimate is as accurate
        > as available data will allow, but still a dishonesty because we _know_ that
        > the estimate is wrong, perhaps only in a small way, but perhaps
        > substantially, and we have no way of knowing which.

        I just tell 'em that this isn't what will happen, but it is a lot like
        what will happen, and that we'll keep 'em informed.

        Tell what you know, and tell what you don't. That's the best I know to
        do.

        Ron Jeffries
        www.XProgramming.com
        You keep using that word. I do not think it means what you think it means.
        --Inigo Montoya
      • Bryan Dollery
        Ron Jeffries wrote ... I like this. It seems more honest. Do you really tell your clients that, or do you believe that they understand that it is a necessary
        Message 3 of 22 , Nov 1, 2001
        • 0 Attachment
          Ron Jeffries wrote
          > Around Thursday, November 01, 2001, 11:12:10 AM, Bryan Dollery wrote:
          >
          > > So, unless I've missed something, we've done something here that isn't
          > > entirely honest. Not a lie, because at the time the estimate is
          > as accurate
          > > as available data will allow, but still a dishonesty because we
          > _know_ that
          > > the estimate is wrong, perhaps only in a small way, but perhaps
          > > substantially, and we have no way of knowing which.
          >
          > I just tell 'em that this isn't what will happen, but it is a lot like
          > what will happen, and that we'll keep 'em informed.

          I like this. It seems more honest. Do you really tell your clients that, or
          do you believe that they understand that it is a necessary consequence of
          their request?

          > Tell what you know, and tell what you don't. That's the best I know to
          > do.

          I think that we can agree on that.

          Bryan
        • Ron Jeffries
          ... I tell them that. Stole the idea from Beck: He told the CIO of Chrysler exactly that. This isn t what is going to happen. Ron Jeffries
          Message 4 of 22 , Nov 1, 2001
          • 0 Attachment
            Around Thursday, November 01, 2001, 11:51:06 AM, Bryan Dollery wrote:

            > I like this. It seems more honest. Do you really tell your clients that, or
            > do you believe that they understand that it is a necessary consequence of
            > their request?

            I tell them that. Stole the idea from Beck: He told the CIO of
            Chrysler exactly that. "This isn't what is going to happen."

            Ron Jeffries
            www.XProgramming.com
            The Great and Powerful Oz has spoken.
          Your message has been successfully submitted and would be delivered to recipients shortly.