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

Re: [XP] prioritizing stories

Expand Messages
  • Ron Jeffries
    ... If it works for you, do it. The value to the release plan is that your customer and other stakeholders get a view of what you ll release and when. Are you
    Message 1 of 22 , Nov 1, 2001
      Around Thursday, November 01, 2001, 10:12:23 AM, Brian C. Robinson wrote:

      > This seems kind of BDUFish to me. Our customer only writes stories a few
      > iterations ahead of time. We rarely have more than 25 active or ready
      > stories at a given time. We find that our requirements change frequently
      > enough that if we did any more ahead of time we would end up tossing them
      > all anyway.

      If it works for you, do it. The value to the release plan is that your
      customer and other stakeholders get a view of what you'll release and
      when. Are you releasing all the time anyway?

      We felt at the time that payroll could only be released when it all
      worked, so we needed to know when we'd be done. Turns out I now think
      we could have -- and should have -- released incrementally. Live and
      learn.

      Ron Jeffries
      www.XProgramming.com
      Sigs are like I Ching or Tarot. They don't mean anything,
      but sometimes if you think about them you'll get a useful idea.
    • Bryan Dollery
      Ron Jeffries wrote ... How would the release plan work? If you can t predict what will be built because of the neccessity of change, then how would a release
      Message 2 of 22 , Nov 1, 2001
        Ron Jeffries wrote
        > If it works for you, do it. The value to the release plan is that your
        > customer and other stakeholders get a view of what you'll release and
        > when. Are you releasing all the time anyway?

        How would the release plan work? If you can't predict what will be built
        because of the neccessity of change, then how would a release plan help? I
        can see the possibility of a release schedule, so we can tell the customer
        when the deadlines are (eg: every two weeks for an internal release, every
        two months for a limited release, every six months for a full release,
        etc.), but saying "we'll deliver the portion of the app that does X on date
        Y" seems a little difficult without oricular powers, unless the timescale is
        only a few weeks, which makes it an iteration plan, and I get the idea that
        you're not talking about an iteration plan.

        Bryan
      • Ron Jeffries
        ... 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
        Message 3 of 22 , Nov 1, 2001
          Around Thursday, November 01, 2001, 9:34:55 AM, Bryan Dollery wrote:

          > How would the release plan work? If you can't predict what will be built
          > because of the neccessity of change, then how would a release plan help? I
          > can see the possibility of a release schedule, so we can tell the customer
          > when the deadlines are (eg: every two weeks for an internal release, every
          > two months for a limited release, every six months for a full release,
          > etc.), but saying "we'll deliver the portion of the app that does X on date
          > Y" seems a little difficult without oricular powers, unless the timescale is
          > only a few weeks, which makes it an iteration plan, and I get the idea that
          > you're not talking about an iteration plan.

          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.

          In a product company this is especially important, as folks have to
          line up advertising, tell customers what is coming, and so on.

          In your case, do people want to know what will be in the two-month
          release, and even more so to know what will be in the full release?
          It's nice to have something to tell them.

          I find that without a release plan and date in mind, the customer
          sometimes has difficulty deciding what to do, and winds up kind of
          wandering in feature space. The exercise of deciding what NOT to do
          helps keep focus on what should be done.

          For those of you doing iteration plans only: what are your experiences
          with getting good releases, keeping your stakeholders at bay, and
          having the world be ready for your release?

          Ron Jeffries
          www.XProgramming.com
          Bang, bang, Jeffries' silver hammer came down upon their heads ...
        • Bryan Dollery
          Ron Jeffries wrote ... 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
          Message 4 of 22 , Nov 1, 2001
            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
            elicidate?

            > 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. 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.

            Bryan
          • Ron Jeffries
            ... 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,
            Message 5 of 22 , Nov 1, 2001
              Around Thursday, November 01, 2001, 10:04:27 AM, Bryan Dollery 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
              > elicidate?

              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.

              >> 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.

              > 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.

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

              Ron Jeffries
              www.XProgramming.com
              Discontinue reading if rash, irritation, redness, or swelling develops.
              Especially irritation.
            • Brian C. Robinson
              ... Yeah, we have a release most days. The only time we don t is when there s a nasty bug we can t figure out for a few days and so we don t commit. Wish
              Message 6 of 22 , Nov 1, 2001
                Ron Jeffries made a strange utterance something like this:
                >If it works for you, do it. The value to the release plan is that your
                >customer and other stakeholders get a view of what you'll release and
                >when. Are you releasing all the time anyway?

                Yeah, we have a release most days. The only time we don't is when there's
                a nasty bug we can't figure out for a few days and so we don't
                commit. Wish that would happen less often.


                --
                "The best programmers that I have ever met have an amazing ability to make
                nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...
              • Ivan Tomek
                Thanks to all who answered my original question. I must reiterate that I was talking in an academice course context with very little time available, a
                Message 7 of 22 , Nov 1, 2001
                  Thanks to all who answered my original question. I must reiterate that I was
                  talking in an academice course context with very little time available, a
                  non-trivial project, and a concern that we might never get beyond story
                  estimation if we estimated all stories.

                  However, I still don't see anything wrong with the customer saying 'here are
                  my 300 stories and I would like to implement them all, but these 50 are so
                  low on my priority list that you should not be spending any time estimating
                  them now'. I even feel that it agrees with the general spirit of XP, the
                  principles of 'you are not going to need it' or even 'do the simplest thing
                  first' although I realize that that is not their true application.

                  Ivan


                  > -----Original Message-----
                  > From: Ron Jeffries [mailto:ronjeffries@...]
                  > Sent: Thursday, November 01, 2001 11:23 AM
                  > To: extremeprogramming@yahoogroups.com
                  > Subject: Re: [XP] prioritizing stories
                  >
                  >
                  > Around Thursday, November 01, 2001, 10:04:27 AM, Bryan Dollery 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
                  > > elicidate?
                  >
                  > 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.
                  >
                  > >> 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.
                  >
                  > > 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.
                  >
                  > But tell us how it's working for you, especially regarding people who
                  > want to know what you're going to deliver by when?
                  >
                  > Ron Jeffries
                  > www.XProgramming.com
                  > Discontinue reading if rash, irritation, redness, or swelling
                  > develops.
                  > Especially irritation.
                  >
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  > extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  >
                  > Your use of Yahoo! Groups is subject to
                  > http://docs.yahoo.com/info/terms/
                  >
                  >


                  [Non-text portions of this message have been removed]
                • 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 8 of 22 , Nov 1, 2001
                    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 9 of 22 , Nov 1, 2001
                      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 10 of 22 , Nov 1, 2001
                        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 11 of 22 , Nov 1, 2001
                          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.