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

[XP] prioritizing stories

Expand Messages
  • Ivan Tomek
    Hi, My understanding of the first steps in the XP process is that the customer writes all user stories, the team estimates them all, the customer prioritizes,
    Message 1 of 22 , Oct 30, 2001
      Hi,

      My understanding of the first steps in the XP process is that the customer
      writes all user stories, the team estimates them all, the customer
      prioritizes, the developers and the customer assign stories to releases,
      etc.

      We are now doing a project in a course and the number of stories far exceeds
      what we can implement within the time limits. And not only that - I think
      that if we started by estimating all stories, we would not have any time
      left to start implementing them.

      So my question is: Why doesn't the customer prioritize the stories before
      they are estimated and the team then estimates the stories essentially
      incrementally in the prioritized order, 'just in time'. The set of estimated
      stories would be some superset of what can be achieved in a release or two
      to give the customer some choice, but would still be a (possibly small)
      subset of the total.

      Is there anything wrong with this?

      Ivan


      [Non-text portions of this message have been removed]
    • Dossy
      ... If it works for you, no, there s nothing wrong with it. The whole point is just to give the Customer opportunities to steer. If they prioritize first and
      Message 2 of 22 , Oct 30, 2001
        On 2001.10.30, Ivan Tomek <ivan.tomek@...> wrote:
        > We are now doing a project in a course and the number of stories far exceeds
        > what we can implement within the time limits. And not only that - I think
        > that if we started by estimating all stories, we would not have any time
        > left to start implementing them.
        >
        > So my question is: Why doesn't the customer prioritize the stories before
        > they are estimated and the team then estimates the stories essentially
        > incrementally in the prioritized order, 'just in time'. The set of estimated
        > stories would be some superset of what can be achieved in a release or two
        > to give the customer some choice, but would still be a (possibly small)
        > subset of the total.
        >
        > Is there anything wrong with this?

        If it works for you, no, there's nothing wrong with it.

        The whole point is just to give the Customer opportunities to steer.
        If they prioritize first and aren't given the chance to re-prioritze,
        then what's the point of having developers give estimates at all?

        The flipside is, as you said, developers can spend all their time
        estimating and not enough time implementing.

        The trade-off: the Customer asks developers to estimate on a
        reasonable number of stories, then prioritizes. If they feel
        it necessary, they can ask the developers to estimate some more
        stories -- they have to acknowledge that they do this at the
        cost of developer time that could be spent implementing.

        Of course, if the Customer feels strongly enough to ask for
        more estimates, we should be happy to oblige them.

        -- Dossy

        --
        Dossy Shiobara mail: dossy@...
        Panoptic Computer Network web: http://www.panoptic.com/
        "He realized the fastest way to change is to laugh at your own
        folly -- then you can let go and quickly move on." (p. 70)
      • Ron Jeffries
        ... Yes. ... C3 could estimate 150 to 300 stories in a morning. What s up with you guys? ;-) Remember, they re only estimates. ... Yes. There is a mid range of
        Message 3 of 22 , Oct 30, 2001
          Around Tuesday, October 30, 2001, 3:50:32 PM, Ivan Tomek wrote:

          > My understanding of the first steps in the XP process is that the customer
          > writes all user stories, the team estimates them all, the customer
          > prioritizes, the developers and the customer assign stories to releases,
          > etc.

          Yes.

          > We are now doing a project in a course and the number of stories far exceeds
          > what we can implement within the time limits. And not only that - I think
          > that if we started by estimating all stories, we would not have any time
          > left to start implementing them.

          C3 could estimate 150 to 300 stories in a morning. What's up with you
          guys? ;-) Remember, they're only estimates.

          > So my question is: Why doesn't the customer prioritize the stories before
          > they are estimated and the team then estimates the stories essentially
          > incrementally in the prioritized order, 'just in time'. The set of estimated
          > stories would be some superset of what can be achieved in a release or two
          > to give the customer some choice, but would still be a (possibly small)
          > subset of the total.

          > Is there anything wrong with this?

          Yes. There is a mid range of stories that will be done if they are
          inexpensive enough. Cost is part of the decision process.

          However, it certainly makes sense not to estimate stories that the
          customer knows are LOW priority. You might try that.

          Also consider giving a less precise estimate, like 1 week, 2 weeks, 3
          weeks, Really Hard. Then the customer can use that to decide what to
          do.

          How does that sound?

          Ron Jeffries
          www.XProgramming.com
          Steering is more important than speed,
          in driving and in software development.
        • emeade@geekfarm.org
          ... customer ... releases, ... Ron when you started on C3 did you have all the customer s user stories? -- Erik Meade emeade@objectmentor.com
          Message 4 of 22 , Oct 30, 2001
            --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
            > Around Tuesday, October 30, 2001, 3:50:32 PM, Ivan Tomek wrote:
            >
            > > My understanding of the first steps in the XP process is that the
            customer
            > > writes all user stories, the team estimates them all, the customer
            > > prioritizes, the developers and the customer assign stories to
            releases,
            > > etc.
            >
            > Yes.

            Ron when you started on C3 did you have all the customer's user
            stories?

            --
            Erik Meade emeade@...
            Senior Consultant Object Mentor, Inc.
            http://www.junit.org
          • Ron Jeffries
            ... No. We had about 150 or 180. We had placeholders for all the known areas where stories would be coming, and discussion with the Customer as to what they
            Message 5 of 22 , Oct 30, 2001
              Around Tuesday, October 30, 2001, 6:58:24 PM, emeade@... wrote:

              > In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
              >> Around Tuesday, October 30, 2001, 3:50:32 PM, Ivan Tomek wrote:
              >>
              >> > My understanding of the first steps in the XP process is that the
              > customer
              >> > writes all user stories, the team estimates them all, the customer
              >> > prioritizes, the developers and the customer assign stories to
              > releases,
              >> > etc.
              >>
              >> Yes.

              > Ron when you started on C3 did you have all the customer's user
              > stories?

              No. We had about 150 or 180. We had placeholders for all the known
              areas where stories would be coming, and discussion with the Customer
              as to what they were about. I'd guess we had over 80 percent of the
              important stuff.

              Ron Jeffries
              www.XProgramming.com
              Do, or do not. There is no try. --Yoda
            • kentbeck@csi.com
              I tell people to start implementing when they are pretty sure there aren t more important stories out there. An iteration s worth of data is worth months of
              Message 6 of 22 , Oct 30, 2001
                I tell people to start implementing when they are pretty sure there
                aren't more important stories out there. An iteration's worth of data
                is worth months of speculation.

                Kent

                --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                > Around Tuesday, October 30, 2001, 6:58:24 PM, emeade@g... wrote:
                >
                > > In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...>
                wrote:
                > >> Around Tuesday, October 30, 2001, 3:50:32 PM, Ivan Tomek wrote:
                > >>
                > >> > My understanding of the first steps in the XP process is that
                the
                > > customer
                > >> > writes all user stories, the team estimates them all, the
                customer
                > >> > prioritizes, the developers and the customer assign stories to
                > > releases,
                > >> > etc.
                > >>
                > >> Yes.
                >
                > > Ron when you started on C3 did you have all the customer's user
                > > stories?
                >
                > No. We had about 150 or 180. We had placeholders for all the known
                > areas where stories would be coming, and discussion with the
                Customer
                > as to what they were about. I'd guess we had over 80 percent of the
                > important stuff.
                >
                > Ron Jeffries
                > www.XProgramming.com
                > Do, or do not. There is no try. --Yoda
              • Doug Swartz
                ... For what it s worth: we also find that somewhere between 70% and 80% of the stories which end up getting implemented are present at the first release plan.
                Message 7 of 22 , Oct 30, 2001
                  Ron Jeffries wrote:

                  > >> Around Tuesday, October 30, 2001, 3:50:32 PM, Ivan Tomek wrote:

                  > > Ron when you started on C3 did you have all the customer's user stories?

                  > No. We had about 150 or 180. We had placeholders for all the known
                  > areas where stories would be coming, and discussion with the Customer
                  > as to what they were about. I'd guess we had over 80 percent of the
                  > important stuff.

                  For what it's worth: we also find that somewhere between 70% and 80% of the stories
                  which end up getting implemented are present at the first release plan.

                  Does anyone else have statistics about implemented projects and when the stories show
                  up? Do these statistics have any meaning?

                  Doug Swartz
                  daswartz@...
                • Ron Jeffries
                  ... We were planning a project that took 14 programmers one year, and that resulted in about 250,000 lines of Smalltalk. That s equivalent to, what, a million
                  Message 8 of 22 , Oct 31, 2001
                    Around Wednesday, October 31, 2001, 10:26:29 AM, Brian C. Robinson wrote:

                    > Ron Jeffries made a strange utterance something like this:
                    >>C3 could estimate 150 to 300 stories in a morning. What's up with you
                    >>guys? ;-) Remember, they're only estimates.

                    > Seriously, why would you ever have that many stories? We've been doing XP
                    > for 10 months and I think we only have in the neighborhood of 150-200
                    > stories. And those weren't all written at the same time; we usually
                    > produce ten or so an iteration as we find new things we need to do.

                    We were planning a project that took 14 programmers one year, and that
                    resulted in about 250,000 lines of Smalltalk. That's equivalent to,
                    what, a million lines of Java or C++, according to Capers Jones?

                    Lots of function points. And Release Planning is important, to give
                    the customer and stakeholders a view of where you are and where you're
                    going. Dropping RP after a couple of years may have been C3's biggest
                    mistake.

                    Ron Jeffries
                    www.XProgramming.com
                    You can observe a lot by watching. --Yogi Berra
                  • Brian C. Robinson
                    ... Seriously, why would you ever have that many stories? We ve been doing XP for 10 months and I think we only have in the neighborhood of 150-200 stories.
                    Message 9 of 22 , Oct 31, 2001
                      Ron Jeffries made a strange utterance something like this:
                      >C3 could estimate 150 to 300 stories in a morning. What's up with you
                      >guys? ;-) Remember, they're only estimates.

                      Seriously, why would you ever have that many stories? We've been doing XP
                      for 10 months and I think we only have in the neighborhood of 150-200
                      stories. And those weren't all written at the same time; we usually
                      produce ten or so an iteration as we find new things we need to do.


                      --
                      "The best programmers that I have ever met have an amazing ability to make
                      nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...
                    • Bryan Dollery
                      Ivan Tomek wrote ... Only that really big stories, with apparently high priority get split into smaller stories, only some of which are high priority; the
                      Message 10 of 22 , Oct 31, 2001
                        Ivan Tomek wrote
                        > Hi,
                        >
                        > My understanding of the first steps in the XP process is that the customer
                        > writes all user stories, the team estimates them all, the customer
                        > prioritizes, the developers and the customer assign stories to releases,
                        > etc.
                        >
                        > We are now doing a project in a course and the number of stories
                        > far exceeds
                        > what we can implement within the time limits. And not only that - I think
                        > that if we started by estimating all stories, we would not have any time
                        > left to start implementing them.
                        >
                        > So my question is: Why doesn't the customer prioritize the stories before
                        > they are estimated and the team then estimates the stories essentially
                        > incrementally in the prioritized order, 'just in time'. The set
                        > of estimated
                        > stories would be some superset of what can be achieved in a release or two
                        > to give the customer some choice, but would still be a (possibly small)
                        > subset of the total.
                        >
                        > Is there anything wrong with this?

                        Only that really big stories, with apparently high priority get split into
                        smaller stories, only some of which are high priority; the split is based on
                        the estimate. No estimate, no split, no accuracy of priority.

                        Bryan
                      • 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 11 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 12 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 13 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 14 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
                              • Brian C. Robinson
                                ... 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
                                Message 15 of 22 , Nov 1, 2001
                                  Ron Jeffries made a strange utterance something like this:
                                  >Around Wednesday, October 31, 2001, 10:26:29 AM, Brian C. Robinson wrote:
                                  > > Seriously, why would you ever have that many stories? We've been doing XP
                                  > > for 10 months and I think we only have in the neighborhood of 150-200
                                  > > stories. And those weren't all written at the same time; we usually
                                  > > produce ten or so an iteration as we find new things we need to do.
                                  >
                                  >We were planning a project that took 14 programmers one year, and that
                                  >resulted in about 250,000 lines of Smalltalk.

                                  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.


                                  --
                                  "The best programmers that I have ever met have an amazing ability to make
                                  nasty sh*t disappear. *Poof*" Gareth Reeves -- reevesg@...
                                • 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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.