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

How to prevent scope creep in XP projects?

Expand Messages
  • weedogt66
    We have been running extreme programming for some time now in my company. Mostly people are happy what they see. But one thing has been really troubelsome;
    Message 1 of 24 , Oct 12, 2005
      We have been running extreme programming for some time now in my
      company. Mostly people are happy what they see. But one thing has
      been really troubelsome; increased scope creep.

      When we present a new release to the customer he is happy but also
      gets about a hundred new ideas on how to improve the system. Can you
      do that also? And this would be better if... And, by the way, I would
      like a... And so on.

      Some functionality is removed for the to-do list each iteration but
      that is not enough to compensate for all the new stuff. I'm afraid
      that when the project ends we will have a looong list of not done
      user stories. I'm afraid that it will not look so good in the eyes of
      the customer. From his point of view we didn't meet his expectations.

      I guess I need a couple of good arguments regarding why the customer
      has to accept that adding one user story often means that he will
      loose another.

      Or am I asking the wrong question? Is there a better approach?

      /anders
    • Tim Haughton
      XP doesn t just embrace changing requirements, it encourages them. Changes in requirements always happen as a customer sees the product grow, gets new ideas
      Message 2 of 24 , Oct 12, 2005
        XP doesn't just embrace changing requirements, it encourages them. Changes
        in requirements always happen as a customer sees the product grow, gets new
        ideas and a better understanding.
        The only problem that you seem to have is that the customer isn't getting
        the feedback she needs to take a measured approach to change.
        I'd reccomend burn up/down charts. These give a tangible picture to the
        customer, a picture of the decision they just made, and the impact it had.
        Cheers,
        Tim Haughton

        On 12/10/05, weedogt66 <weedogt@...> wrote:
        >
        > We have been running extreme programming for some time now in my
        > company. Mostly people are happy what they see. But one thing has
        > been really troubelsome; increased scope creep.
        >
        > When we present a new release to the customer he is happy but also
        > gets about a hundred new ideas on how to improve the system. Can you
        > do that also? And this would be better if... And, by the way, I would
        > like a... And so on.
        >
        > Some functionality is removed for the to-do list each iteration but
        > that is not enough to compensate for all the new stuff. I'm afraid
        > that when the project ends we will have a looong list of not done
        > user stories. I'm afraid that it will not look so good in the eyes of
        > the customer. From his point of view we didn't meet his expectations.
        >
        > I guess I need a couple of good arguments regarding why the customer
        > has to accept that adding one user story often means that he will
        > loose another.
        >
        > Or am I asking the wrong question? Is there a better approach?
        >
        > /anders
        >
        >
        >
        >
        >
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com <http://objectmentor.com>
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Ron Jeffries
        Anders ... do you do a release plan? Do you maintain a burn chart? Ron Jeffries www.XProgramming.com Questioner: How do I sell my executive team on doing this
        Message 3 of 24 , Oct 12, 2005
          Anders ... do you do a release plan? Do you maintain a burn chart?

          Ron Jeffries
          www.XProgramming.com
          Questioner: How do I sell my executive team on doing this stuff?
          Jim Highsmith: Don't. Just do it. They don't know what you're doing anyway.


          On Wednesday, October 12, 2005, at 10:24:51 AM, weedogt66 wrote:

          > We have been running extreme programming for some time now in my
          > company. Mostly people are happy what they see. But one thing has
          > been really troubelsome; increased scope creep.

          > When we present a new release to the customer he is happy but also
          > gets about a hundred new ideas on how to improve the system. Can you
          > do that also? And this would be better if... And, by the way, I would
          > like a... And so on.

          > Some functionality is removed for the to-do list each iteration but
          > that is not enough to compensate for all the new stuff. I'm afraid
          > that when the project ends we will have a looong list of not done
          > user stories. I'm afraid that it will not look so good in the eyes of
          > the customer. From his point of view we didn't meet his expectations.

          > I guess I need a couple of good arguments regarding why the customer
          > has to accept that adding one user story often means that he will
          > loose another.

          > Or am I asking the wrong question? Is there a better approach?
        • Victor
          It seems like the central idea is that the implementation of the customer ideas is on their dime. The customer has to be made aware of the cost. If they are
          Message 4 of 24 , Oct 12, 2005
            It seems like the central idea is that the implementation of the customer
            ideas is on their dime. The customer has to be made aware of the cost. If
            they are happy to foot the bill, I guess everybody is happy.

            Victor

            ==========================================

            ----- Original Message -----
            From: "weedogt66" <weedogt@...>
            To: <extremeprogramming@yahoogroups.com>
            Sent: Wednesday, October 12, 2005 10:24 AM
            Subject: [XP] How to prevent scope creep in XP projects?


            > We have been running extreme programming for some time now in my
            > company. Mostly people are happy what they see. But one thing has
            > been really troubelsome; increased scope creep.
            >
            > When we present a new release to the customer he is happy but also
            > gets about a hundred new ideas on how to improve the system. Can you
            > do that also? And this would be better if... And, by the way, I would
            > like a... And so on.
            >
            > Some functionality is removed for the to-do list each iteration but
            > that is not enough to compensate for all the new stuff. I'm afraid
            > that when the project ends we will have a looong list of not done
            > user stories. I'm afraid that it will not look so good in the eyes of
            > the customer. From his point of view we didn't meet his expectations.
            >
            > I guess I need a couple of good arguments regarding why the customer
            > has to accept that adding one user story often means that he will
            > loose another.
            >
            > Or am I asking the wrong question? Is there a better approach?
            >
            > /anders
            >
            >
            >
            >
            >
            >
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >
          • Daryl Richter
            ... Because time is immutable? Because *he* told you he wanted this before that? ... You say the customer is happy. The problem is...? ... [snipped old ads]
            Message 5 of 24 , Oct 12, 2005
              On Oct 12, 2005, at 10:24 AM, weedogt66 wrote:


              > We have been running extreme programming for some time now in my
              > company. Mostly people are happy what they see. But one thing has
              > been really troubelsome; increased scope creep.
              >
              > When we present a new release to the customer he is happy but also
              > gets about a hundred new ideas on how to improve the system. Can you
              > do that also? And this would be better if... And, by the way, I would
              > like a... And so on.
              >


              > Some functionality is removed for the to-do list each iteration but
              > that is not enough to compensate for all the new stuff. I'm afraid
              > that when the project ends we will have a looong list of not done
              > user stories. I'm afraid that it will not look so good in the eyes of
              > the customer. From his point of view we didn't meet his expectations.
              >
              > I guess I need a couple of good arguments regarding why the customer
              > has to accept that adding one user story often means that he will
              > loose another.
              >
              >

              Because time is immutable? Because *he* told you he wanted this
              before that?


              > Or am I asking the wrong question? Is there a better approach?
              >
              >

              You say the customer is happy. The problem is...?


              > /anders
              >
              >

              [snipped old ads]

              --
              Daryl
            • Tony Byrne
              Hello weedogt66, Wednesday, October 12, 2005, 3:24:51 PM, you wrote: w When we present a new release to the customer he is happy but also w gets about a
              Message 6 of 24 , Oct 12, 2005
                Hello weedogt66,

                Wednesday, October 12, 2005, 3:24:51 PM, you wrote:

                w> When we present a new release to the customer he is happy but also
                w> gets about a hundred new ideas on how to improve the system. Can you
                w> do that also? And this would be better if... And, by the way, I would
                w> like a... And so on.

                A certain amount of this is to be expected, development of good
                software is a learning process for everyone involved. I've certainly
                worked with customers who needed the feedback of working software in
                order to sort out their 'real' requirements. It's just one of many
                feedback loops.

                If there's excessive scope creep then maybe it points to a lack of
                forethought and discussion about the stories. I would also think that
                having acceptance tests for stories would help the team to uncover
                surprises earlier.

                w> I guess I need a couple of good arguments regarding why the customer
                w> has to accept that adding one user story often means that he will
                w> loose another.

                Well your team has finite development capacity per iteration and maybe
                you are also facing a deadline of some sort. It may not be possible to
                complete all of the stories within the available time with the current
                capacity. Whenever you have too much to do the customer needs to
                steer by prioritizing the work so the most valuable stories delivered.

                Regards,

                Tony.

                --
                Tony Byrne
              • William Pietri
                Hi, Anders! ... Who does the removing? If it s not the customer, that might be your source of the trouble. William
                Message 7 of 24 , Oct 12, 2005
                  Hi, Anders!

                  weedogt66 wrote:

                  >When we present a new release to the customer he is happy but also
                  >gets about a hundred new ideas on how to improve the system. Can you
                  >do that also? And this would be better if... And, by the way, I would
                  >like a... And so on.
                  >
                  >Some functionality is removed for the to-do list each iteration but
                  >that is not enough to compensate for all the new stuff. I'm afraid
                  >that when the project ends we will have a looong list of not done
                  >user stories. I'm afraid that it will not look so good in the eyes of
                  >the customer. From his point of view we didn't meet his expectations.
                  >
                  >

                  Who does the removing? If it's not the customer, that might be your
                  source of the trouble.

                  William
                • William Pietri
                  ... Yes and no. That means the customer will be happy with the developers, but that doesn t mean the project will succeed. A venture capitalist advising one of
                  Message 8 of 24 , Oct 12, 2005
                    Victor wrote:

                    >It seems like the central idea is that the implementation of the customer
                    >ideas is on their dime. The customer has to be made aware of the cost. If
                    >they are happy to foot the bill, I guess everybody is happy.
                    >
                    >

                    Yes and no. That means the customer will be happy with the developers,
                    but that doesn't mean the project will succeed. A venture capitalist
                    advising one of my clients recently said, "Money in the bank has caused
                    more bad software decisions than any other single thing."

                    Without frequent releases and other sorts of real-world feedback, XP can
                    succeed in fashion that I think of as, "The operation was successful but
                    the patient died." Scope creep to me is a sign that there's not enough
                    pressure to release.

                    William
                  • Kent Beck
                    Anders, Your scenario seems clear to me--the customer likes what he is getting and he has ideas for more features he would like. Whether those ideas turn into
                    Message 9 of 24 , Oct 12, 2005
                      Anders,

                      Your scenario seems clear to me--the customer likes what he is getting and
                      he has ideas for more features he would like. Whether those ideas turn into
                      a positive for your relationship or a negative is what is in question.
                      Trying to put myself in your customer's shoes for a second, I can think of
                      several scenarios:
                      * The new features obsolete the existing features.
                      * The new features are necessary to make the system function, but I still
                      need everything you already committed to delivering.
                      * The new features would be valuable to have, but I would still like the
                      already-committed features delivered and deployed first.

                      How I as a customer react to all of these scenarios seems to hinge on my
                      relationship with you, how you've acted to date. I read a general business
                      article recently that stated that what partners are looking for are
                      benevolence, integrity, and skill. If you have demonstrated benevolence (you
                      have my interests in mind, not just your own), integrity (you say what you
                      will do and you do it), and skill (you are good at what you do); then I am
                      likely to trust you to continue, regardless whether the project is in
                      trouble or merely faced with overwhelming opportunities.

                      The point of your post seems to be in the second-to-last paragraph. It
                      sounds like you would like to lead your customer to think and feel a certain
                      way. When I try to do this, I always lose. I can't, in reality, control
                      anyone else's thoughts or feelings, and the time and energy I spend trying
                      keeps me from doing my best. I liked the earlier suggestion of a burndown
                      chart, not as a way to "force" the customer to "be realistic", but as a way
                      of clearly expressing the way you see the situation.

                      Sincerely yours,

                      Kent Beck
                      Three Rivers Institute

                      > -----Original Message-----
                      > From: extremeprogramming@yahoogroups.com
                      > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of weedogt66
                      > Sent: Wednesday, October 12, 2005 7:25 AM
                      > To: extremeprogramming@yahoogroups.com
                      > Subject: [XP] How to prevent scope creep in XP projects?
                      >
                      > We have been running extreme programming for some time now in my
                      > company. Mostly people are happy what they see. But one thing has
                      > been really troubelsome; increased scope creep.
                      >
                      > When we present a new release to the customer he is happy but also
                      > gets about a hundred new ideas on how to improve the system. Can you
                      > do that also? And this would be better if... And, by the way, I would
                      > like a... And so on.
                      >
                      > Some functionality is removed for the to-do list each iteration but
                      > that is not enough to compensate for all the new stuff. I'm afraid
                      > that when the project ends we will have a looong list of not done
                      > user stories. I'm afraid that it will not look so good in the eyes of
                      > the customer. From his point of view we didn't meet his expectations.
                      >
                      > I guess I need a couple of good arguments regarding why the customer
                      > has to accept that adding one user story often means that he will
                      > loose another.
                      >
                      > Or am I asking the wrong question? Is there a better approach?
                      >
                      > /anders
                    • J. B. Rainsberger
                      ... Mr. Customer, if you add 23 points to our plan, you have to take 23 points out of the plan. If you don t, then it s not a plan, it s a dream. Of course,
                      Message 10 of 24 , Oct 12, 2005
                        weedogt66 wrote:
                        > We have been running extreme programming for some time now in my
                        > company. Mostly people are happy what they see. But one thing has
                        > been really troubelsome; increased scope creep.
                        >
                        > When we present a new release to the customer he is happy but also
                        > gets about a hundred new ideas on how to improve the system. Can you
                        > do that also? And this would be better if... And, by the way, I would
                        > like a... And so on.
                        >
                        > Some functionality is removed for the to-do list each iteration but
                        > that is not enough to compensate for all the new stuff. I'm afraid
                        > that when the project ends we will have a looong list of not done
                        > user stories. I'm afraid that it will not look so good in the eyes of
                        > the customer. From his point of view we didn't meet his expectations.
                        >
                        > I guess I need a couple of good arguments regarding why the customer
                        > has to accept that adding one user story often means that he will
                        > loose another.
                        >
                        > Or am I asking the wrong question? Is there a better approach?

                        "Mr. Customer, if you add 23 points to our plan, you have to take 23
                        points out of the plan. If you don't, then it's not a plan, it's a dream."

                        Of course, you might want to soften the tone a little, but that's the
                        bottom line.
                        --
                        J. B. (Joe) Rainsberger
                        Diaspar Software Services
                        http://www.diasparsoftware.com
                        2005 Gordon Pask Award Winner for contribution to Agile practice
                        Author, JUnit Recipes: Practical Methods for Programmer Testing
                      • Steven Gordon
                        If I may suggest what Anders problem might be (or if not, the kind of problem somebody else could have in his scenario): The customer might be very happy, but
                        Message 11 of 24 , Oct 12, 2005
                          If I may suggest what Anders' problem might be (or if not, the kind of
                          problem somebody else could have in his scenario):
                          The customer might be very happy, but management might not be. For example,
                          this might have been an internal project scheduled in the context of a
                          portfolio of projects under the assumption that the originally scheduled
                          functionality would be accomplished in the originally scheduled time. It
                          could even be that other projects in the portfolio were dependent on certain
                          features that the customers traded for features they thought were more
                          "cool".
                          Setting management expectations can be as important as setting customer
                          expectations. Keeping management regularly informed of both the iterative
                          growth of implemented story points and the iterative growth of the total
                          number of story points (i.e. scope) can be as important as keeping the
                          customer informed. This is why I prefer the burnup chart (with a graph of
                          both delivered stories and total stories plotted against time) over the
                          burndown chart (a graph of just the unimplemented stories plotted against
                          time).
                          Steven Gordon
                          On 10/12/05, Kent Beck <kentb@...> wrote:
                          >
                          > Anders,
                          >
                          > Your scenario seems clear to me--the customer likes what he is getting and
                          > he has ideas for more features he would like. Whether those ideas turn
                          > into
                          > a positive for your relationship or a negative is what is in question.
                          > Trying to put myself in your customer's shoes for a second, I can think of
                          > several scenarios:
                          > * The new features obsolete the existing features.
                          > * The new features are necessary to make the system function, but I still
                          > need everything you already committed to delivering.
                          > * The new features would be valuable to have, but I would still like the
                          > already-committed features delivered and deployed first.
                          >
                          > How I as a customer react to all of these scenarios seems to hinge on my
                          > relationship with you, how you've acted to date. I read a general business
                          > article recently that stated that what partners are looking for are
                          > benevolence, integrity, and skill. If you have demonstrated benevolence
                          > (you
                          > have my interests in mind, not just your own), integrity (you say what you
                          > will do and you do it), and skill (you are good at what you do); then I am
                          > likely to trust you to continue, regardless whether the project is in
                          > trouble or merely faced with overwhelming opportunities.
                          >
                          > The point of your post seems to be in the second-to-last paragraph. It
                          > sounds like you would like to lead your customer to think and feel a
                          > certain
                          > way. When I try to do this, I always lose. I can't, in reality, control
                          > anyone else's thoughts or feelings, and the time and energy I spend trying
                          > keeps me from doing my best. I liked the earlier suggestion of a burndown
                          > chart, not as a way to "force" the customer to "be realistic", but as a
                          > way
                          > of clearly expressing the way you see the situation.
                          >
                          > Sincerely yours,
                          >
                          > Kent Beck
                          > Three Rivers Institute
                          >
                          > > -----Original Message-----
                          > > From: extremeprogramming@yahoogroups.com
                          > > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of weedogt66
                          > > Sent: Wednesday, October 12, 2005 7:25 AM
                          > > To: extremeprogramming@yahoogroups.com
                          > > Subject: [XP] How to prevent scope creep in XP projects?
                          > >
                          > > We have been running extreme programming for some time now in my
                          > > company. Mostly people are happy what they see. But one thing has
                          > > been really troubelsome; increased scope creep.
                          > >
                          > > When we present a new release to the customer he is happy but also
                          > > gets about a hundred new ideas on how to improve the system. Can you
                          > > do that also? And this would be better if... And, by the way, I would
                          > > like a... And so on.
                          > >
                          > > Some functionality is removed for the to-do list each iteration but
                          > > that is not enough to compensate for all the new stuff. I'm afraid
                          > > that when the project ends we will have a looong list of not done
                          > > user stories. I'm afraid that it will not look so good in the eyes of
                          > > the customer. From his point of view we didn't meet his expectations.
                          > >
                          > > I guess I need a couple of good arguments regarding why the customer
                          > > has to accept that adding one user story often means that he will
                          > > loose another.
                          > >
                          > > Or am I asking the wrong question? Is there a better approach?
                          > >
                          > > /anders
                          >


                          [Non-text portions of this message have been removed]
                        • Dave McMunn
                          Hi, One way we have found that helps prevent scope creep is to have the client essentially put a value on each story. That means first clearly defining the
                          Message 12 of 24 , Oct 13, 2005
                            Hi,

                            One way we have found that helps prevent scope creep is to have the client essentially put a value on each story. That means first clearly defining the release objectives up front. Then, when you define the story and the developers establish the cost, the business establishes quantifies the benefit (based well it achieves the objectives). This was done indepent of the cost. It helped the customer tremendously to get out of the emotion of what they desired and really focus on how it moved the application forward to achieving the business objectives.



                            Tony Byrne <yahoogroups@...> wrote:
                            Hello weedogt66,

                            Wednesday, October 12, 2005, 3:24:51 PM, you wrote:

                            w> When we present a new release to the customer he is happy but also
                            w> gets about a hundred new ideas on how to improve the system. Can you
                            w> do that also? And this would be better if... And, by the way, I would
                            w> like a... And so on.

                            A certain amount of this is to be expected, development of good
                            software is a learning process for everyone involved. I've certainly
                            worked with customers who needed the feedback of working software in
                            order to sort out their 'real' requirements. It's just one of many
                            feedback loops.

                            If there's excessive scope creep then maybe it points to a lack of
                            forethought and discussion about the stories. I would also think that
                            having acceptance tests for stories would help the team to uncover
                            surprises earlier.

                            w> I guess I need a couple of good arguments regarding why the customer
                            w> has to accept that adding one user story often means that he will
                            w> loose another.

                            Well your team has finite development capacity per iteration and maybe
                            you are also facing a deadline of some sort. It may not be possible to
                            complete all of the stories within the available time with the current
                            capacity. Whenever you have too much to do the customer needs to
                            steer by prioritizing the work so the most valuable stories delivered.

                            Regards,

                            Tony.

                            --
                            Tony Byrne




                            To Post a message, send it to: extremeprogramming@...

                            To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                            ad-free courtesy of objectmentor.com
                            Yahoo! Groups Links









                            ---------------------------------
                            Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

                            [Non-text portions of this message have been removed]
                          • Ron Jeffries
                            ... Dave, I d have said at first glance that this notion is somewhat counter to the whole agile notion of embracing change. How would you relate this idea to
                            Message 13 of 24 , Oct 13, 2005
                              On Thursday, October 13, 2005, at 3:23:18 PM, Dave McMunn wrote:

                              > One way we have found that helps prevent scope creep is to have
                              > the client essentially put a value on each story. That means first
                              > clearly defining the release objectives up front. Then, when you
                              > define the story and the developers establish the cost, the
                              > business establishes quantifies the benefit (based well it
                              > achieves the objectives). This was done indepent of the cost. It
                              > helped the customer tremendously to get out of the emotion of what
                              > they desired and really focus on how it moved the application
                              > forward to achieving the business objectives.

                              Dave, I'd have said at first glance that this notion is somewhat
                              counter to the whole agile notion of embracing change. How would you
                              relate this idea to that one?

                              Ron Jeffries
                              www.XProgramming.com
                              Hope is not a strategy. -- Michael Henos
                            • Keith Braithwaite
                              ... Ron, Would you care to take a second glance at Dave s report and then explain how it is that knowing what the value of the (outputs of building) a story is
                              Message 14 of 24 , Oct 14, 2005
                                --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                <ronjeffries@X...> wrote:
                                >
                                > On Thursday, October 13, 2005, at 3:23:18 PM, Dave McMunn wrote:
                                >
                                > > One way we have found that helps prevent scope creep is to have
                                > > the client essentially put a value on each story.[...]It
                                > > helped the customer tremendously to get out of the emotion of what
                                > > they desired and really focus on how it moved the application
                                > > forward to achieving the business objectives.
                                >
                                > Dave, I'd have said at first glance that this notion is somewhat
                                > counter to the whole agile notion of embracing change.

                                > Ron Jeffries


                                Ron,
                                Would you care to take a second glance at Dave's report and then
                                explain how it is that knowing what the value of the (outputs of
                                building) a story is works against embracing change?

                                A related case: I've seen an agile team cranking away, release after
                                relese, nice healthy "velocity", but still be the whipping-boys for
                                poor business performance because they were percieved as wasting time
                                building worthless things. Planning games became shouting matches
                                between proxy customers all yelling that their real customer was the
                                bigger and hairier, or that their strategic internal project was the
                                more important, and so on. No effective steering from the business.
                                Disaster. The developers were pulled from pillar to post, faced with
                                more change than they could hope to cope with, wether they embraced it
                                or not, as one political agenda or account manager's whim won at
                                successive planning games.

                                This was fixed almost instantaneously by requiring the proxy customers
                                to submit purchace orders for the cost of development of their
                                stories. This wasn't an ISV but a service company, so all these PO's
                                represented was the company moving money from one pocket to
                                another--but they focussed attention.

                                Most importantly a proxy customer (now accountable for the cost of
                                developing their stories) had to obtain signoff from their
                                budget-holding manager to raise a PO, and in the usual business way
                                they could only do that off the back of a well-qualified revenue
                                projection or a PO from the real customer. A measure of the value of
                                putting their stories into production. Bang! All of a sudden planning
                                games were short, effective and civil. All of a sudden the priorities
                                for this, the next, and the iteration after that were crystal clear.
                                The team changed from cranking out points of "speed" to cranking out
                                points of velocity in the direction of ROI (unit vector: GBP).

                                Real changes in business need (rather than chages in whim) still
                                occured, could be identified, qualified and executed in just as timely
                                a fashion as before. In fact, I'd estimate that the time taken to
                                qualify a story properly and have it scheduled at the natural point in
                                time was less than the time taken to bully and horse-trade it in uner
                                the old scheme. So change was able to be responded to faster, with
                                better visibility, and better control.

                                I don't understand which bit of this was a reduction in agility.

                                Keith
                              • Keith Braithwaite
                                ... This is good. ... So long as the stories that remain to-do are the highest priority for the customer of all the stories currently known, this is good too.
                                Message 15 of 24 , Oct 14, 2005
                                  --- In extremeprogramming@yahoogroups.com, "weedogt66" <weedogt@h...>
                                  wrote:
                                  > When we present a new release to the customer he is happy but also
                                  > gets about a hundred new ideas on how to improve the system. Can you
                                  > do that also? And this would be better if...
                                  This is good.


                                  > Some functionality is removed for the to-do list each iteration but
                                  > that is not enough to compensate for all the new stuff.
                                  So long as the stories that remain to-do are the highest priority for
                                  the customer of all the stories currently known, this is good too.

                                  > I'm afraid
                                  > that when the project ends we will have a looong list of not done
                                  > user stories. I'm afraid that it will not look so good in the eyes of
                                  > the customer. From his point of view we didn't meet his expectations.
                                  Don't be afraid. One of the most successful XP projects I ever worked
                                  on ended with one third of the total known stories at the end not
                                  implemented and the customer was very, very happy. Note that stories
                                  came in and out all through this project. Some of that third left at
                                  the end had been there from the beginning, some not. This was true of
                                  the two-thirds that got implemented, too.

                                  You say: when we present a new release to the customer he is happy. If
                                  you can keep this true for all releases up to the last one, then after
                                  the last release then the customer will still be happy, right?


                                  > I guess I need a couple of good arguments regarding why the customer
                                  > has to accept that adding one user story often means that he will
                                  > loose another.
                                  It sounds as if he already understands this, since older stories
                                  already are being removed each iteration.

                                  Actually, I don't understand how classical scope creep can occur in an
                                  agile process. To me, scope creep means that since the delivery date
                                  for anything is so far away, and so uncertain, then the customer feels
                                  able to cram random stuff they think of in the meantime into the
                                  requirement as a MUST. But if the next delivery date is a couple of
                                  weeks away, even the most highly developed whishful thinking muscles
                                  will struggle to insert "MUST have telepathic interface" into a
                                  release without being prepared to take something else out.

                                  I wonder, how many agile projects have you executed? Are your fears
                                  born from the fact that you haven't seen an agile project come to a
                                  successful end-point before, so you don't know what is and is not
                                  likely to be acceptable at that point?

                                  Keith
                                • Steven Gordon
                                  ... Agile scope creep is different from traditional scope creep. Traditional scope creep is when release dates get pushed out to accomodate requirement changes
                                  Message 16 of 24 , Oct 14, 2005
                                    On 10/14/05, Keith Braithwaite <Keith.Braithwaite@...> wrote:

                                    > --- In extremeprogramming@yahoogroups.com, "weedogt66" <weedogt@h...>
                                    > wrote:
                                    > Actually, I don't understand how classical scope creep can occur in an
                                    > agile process. To me, scope creep means that since the delivery date
                                    > for anything is so far away, and so uncertain, then the customer feels
                                    > able to cram random stuff they think of in the meantime into the
                                    > requirement as a MUST. But if the next delivery date is a couple of
                                    > weeks away, even the most highly developed whishful thinking muscles
                                    > will struggle to insert "MUST have telepathic interface" into a
                                    > release without being prepared to take something else out.

                                    Agile scope creep is different from traditional scope creep. Traditional
                                    scope creep is when release dates get pushed out to accomodate requirement
                                    changes and/or additions. Agile scope creep would be when the number of
                                    releases gets pushed out to accomodate requirement additions. In both cases,
                                    project completion costs and time still overrun the original estimate.
                                    The main advantage under agile is that a viable system is still released at
                                    the pre-arranged date, however this can be insidious from a management point
                                    of view. Under the traditional approach, the developers and customers are
                                    unhappy when the delivery date are not met. Under agile, the delivery date
                                    will be met, so the developers and customers are happy, yet management will
                                    be unhappy if the project is not over.
                                    Management can avoid agile scope creep by not allowing the number of
                                    releases to increase (it is more a portfolio management issue that a project
                                    management issue). Then, the customer has to make the story tradeoffs in
                                    earnest.


                                    [Non-text portions of this message have been removed]
                                  • Ron Jeffries
                                    ... Well, I may have misunderstood, of course, or may have over-stated my concerns. What I took Dave to be saying was that they looked at all the stories
                                    Message 17 of 24 , Oct 14, 2005
                                      On Friday, October 14, 2005, at 4:38:04 AM, Keith Braithwaite wrote:

                                      >> On Thursday, October 13, 2005, at 3:23:18 PM, Dave McMunn wrote:
                                      >>
                                      >>> One way we have found that helps prevent scope creep is to have
                                      >>> the client essentially put a value on each story.[...]It
                                      >>> helped the customer tremendously to get out of the emotion of what
                                      >>> they desired and really focus on how it moved the application
                                      >>> forward to achieving the business objectives.
                                      >>
                                      >> Dave, I'd have said at first glance that this notion is somewhat
                                      >> counter to the whole agile notion of embracing change.


                                      > Ron,
                                      > Would you care to take a second glance at Dave's report and then
                                      > explain how it is that knowing what the value of the (outputs of
                                      > building) a story is works against embracing change?

                                      Well, I may have misunderstood, of course, or may have over-stated
                                      my concerns.

                                      What I took Dave to be saying was that they looked at all the
                                      stories before they started, gave them all values, and then
                                      proceeded to work that way. He said that this helped to prevent
                                      scope creep. I took this to say that they limited scope changes that
                                      way.

                                      Looking at value is of course one very important thing to do. My
                                      experience is that it starts to come quite naturally when the users
                                      are faced with the cost of alternative stories, when they see that
                                      asking for a change after a story has been done costs them another
                                      story ... and when they focus on "small releases".

                                      To look at release plans, one needs to look at as many of the
                                      important stories as possible. I took Dave to be saying that they
                                      were looking at ALL the stories -- but what he really said was
                                      "define the release objectives", which doesn't necessarily mean
                                      that.

                                      I believe that every project has, and should have, more stories in
                                      mind than can or should be accomplished. I believe that the
                                      fundamental job of the customer is to decide what goes into the
                                      release and what to defer. [1]

                                      I would expect that the up-front value given to a story might change
                                      by the time the story was coming up for implementation. I would
                                      expect new stories to be thought of, some of them perhaps more
                                      important than any stories already in the queue. I think that having
                                      such things happen, and dealing with it smoothly, is what Agile is
                                      all about.

                                      I took Dave's note as saying that they didn't allow those things.
                                      I see upon re-reading that that was my interpretation and Dave
                                      may not have meant that at all. In any case that was why my full
                                      quote was:

                                      >> Dave, I'd have said at first glance that this notion is somewhat
                                      >> counter to the whole agile notion of embracing change. How would you
                                      >> relate this idea to that one?

                                      I wanted to hear whether my first glance was correct and how Dave
                                      would relate his note to the notion of embracing change. I still do
                                      hope to hear that.

                                      > A related case: I've seen an agile team cranking away, release after
                                      > relese, nice healthy "velocity", but still be the whipping-boys for
                                      > poor business performance because they were percieved as wasting time
                                      > building worthless things. Planning games became shouting matches
                                      > between proxy customers all yelling that their real customer was the
                                      > bigger and hairier, or that their strategic internal project was the
                                      > more important, and so on. No effective steering from the business.
                                      > Disaster. The developers were pulled from pillar to post, faced with
                                      > more change than they could hope to cope with, wether they embraced it
                                      > or not, as one political agenda or account manager's whim won at
                                      > successive planning games.

                                      Interesting ... it seems odd to blame development for what is so
                                      clearly the business people's problem. It makes me think that
                                      perhaps the development team was deciding which stories to do in
                                      each iteration. Was that the case?

                                      > This was fixed almost instantaneously by requiring the proxy customers
                                      > to submit purchace orders for the cost of development of their
                                      > stories. This wasn't an ISV but a service company, so all these PO's
                                      > represented was the company moving money from one pocket to
                                      > another--but they focussed attention.

                                      An elegant step. Yet I wonder, given that there was less capacity
                                      than there was desire, why they didn't still fight over whose PO
                                      would be accepted ...

                                      > Most importantly a proxy customer (now accountable for the cost of
                                      > developing their stories) had to obtain signoff from their
                                      > budget-holding manager to raise a PO, and in the usual business way
                                      > they could only do that off the back of a well-qualified revenue
                                      > projection or a PO from the real customer. A measure of the value of
                                      > putting their stories into production. Bang! All of a sudden planning
                                      > games were short, effective and civil. All of a sudden the priorities
                                      > for this, the next, and the iteration after that were crystal clear.
                                      > The team changed from cranking out points of "speed" to cranking out
                                      > points of velocity in the direction of ROI (unit vector: GBP).

                                      Was this because they didn't have enough money to demand all their
                                      stories, so the load on the dev group was not so far over capacity?
                                      I'd have thought that there would still be too much to do.

                                      I'm wondering about how velocity was managed prior to the change,
                                      since velocity correlates directly and linearly with the amount on
                                      the PO. I'd not have expected so big a change.

                                      > Real changes in business need (rather than chages in whim) still
                                      > occured, could be identified, qualified and executed in just as timely
                                      > a fashion as before. In fact, I'd estimate that the time taken to
                                      > qualify a story properly and have it scheduled at the natural point in
                                      > time was less than the time taken to bully and horse-trade it in uner
                                      > the old scheme. So change was able to be responded to faster, with
                                      > better visibility, and better control.

                                      Well, I definitely subscribe to the dictum "If it works, do it," so
                                      I'm good with this. I'm a little surprised that it changed things,
                                      in that PO amount = K*story estimate. I can see that it might reduce
                                      the number of things the product manager was able to order ... but
                                      don't see how it helped with cross-product concerns, my product is
                                      more important than your product.

                                      And I don't see how it was that using simple velocity and
                                      Yesterday's Weather didn't bring about the same thoughts and
                                      discussions.

                                      Again, it worked, that's great. I'll definitely add the idea to my
                                      bag of tricks.

                                      But ... to summarize what I don't understand:

                                      Before:

                                      team can do N points per iteration;
                                      multiple customers with conflicting needs;
                                      team oversubscribed;
                                      story cost in points or hours;
                                      ==> chaos and anger;

                                      After:

                                      team can do M dollars per iteration, K*N;
                                      multiple customers with conflicting needs;
                                      team oversubscribed;
                                      story cost in fake dollars;
                                      ==> sweetness and light;

                                      Though small changes can make big differences, I'm wondering what
                                      happened here, whether there was anything else going on that also
                                      mattered.

                                      > I don't understand which bit of this was a reduction in agility.

                                      I don't think anyone has said that any of it was. Is there some part
                                      of what happened that gives you concern regarding decreased agility?

                                      Ron Jeffries
                                      www.XProgramming.com
                                      Only the hand that erases can write the true thing. -- Meister Eckhart

                                      [1] I first heard the elegant phrase "what to defer" in this context
                                      from Kent Beck, and I use it to this day, because it makes the
                                      necessity for choice clear, but not as harsh as it might be.
                                    • Ron Jeffries
                                      ... [reordered] ... Wow, a loop termination condition proving the result of the algorithm. I love it! And it s so true! ... It is inevitable -- and desirable
                                      Message 18 of 24 , Oct 14, 2005
                                        On Friday, October 14, 2005, at 4:56:32 AM, Keith Braithwaite wrote:

                                        >> I'm afraid
                                        >> that when the project ends we will have a looong list of not done
                                        >> user stories. I'm afraid that it will not look so good in the eyes of
                                        >> the customer. From his point of view we didn't meet his expectations.

                                        [reordered]
                                        > You say: when we present a new release to the customer he is happy. If
                                        > you can keep this true for all releases up to the last one, then after
                                        > the last release then the customer will still be happy, right?

                                        Wow, a loop termination condition proving the result of the
                                        algorithm. I love it! And it's so true!

                                        > Don't be afraid. One of the most successful XP projects I ever worked
                                        > on ended with one third of the total known stories at the end not
                                        > implemented and the customer was very, very happy. Note that stories
                                        > came in and out all through this project. Some of that third left at
                                        > the end had been there from the beginning, some not. This was true of
                                        > the two-thirds that got implemented, too.

                                        It is inevitable -- and desirable -- to have more ideas than you
                                        choose to implement. It's only in thinking of all the things we
                                        might do that we become confident that we've thought of all the
                                        things we ought to do.

                                        An XP/Agile team lets the customer decide what to do, and what to
                                        put off, keeping everyone aware of the cost, and keeping everyone's
                                        eye on the ball (which is usually expressed as a date). We may
                                        always wish for more, but the customer will see that the team is
                                        doing their best to give him what he asks for, and will almost
                                        certainly be happy with the result.

                                        If all this doesn't make the customer happy, I'd be looking for
                                        other causes. I'd look at the communication, the priority setting
                                        (like your $ for points example), whether quality was low, whether
                                        story completion was crisp, things like that.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        The rules are ways of thinking, not ways to avoid thinking.
                                      • Dave McMunn
                                        I guess in my experience there can two types of customer. One customer is the buyer who is funding the project. That person doesn t necessarily get into the
                                        Message 19 of 24 , Oct 14, 2005
                                          I guess in my experience there can two types of customer. One customer is the buyer who is funding the project. That person doesn't necessarily get into the details, but they are responsible for making sure that certain objectives are met in a timetable. The other customer is the actual how sometimes is more concerned about nice to have features than the bigger objectives behind management's release.

                                          On a recent example, we had the day-to-day customer involve with the team. After each iteration she would review the progress to date and frequently come up with new stories that would enhance the application to achieve the specific process that was being worked upon. The concern from Management was that while the application may be improved in the details, they needed to acheive some higher level goals (other major components needed to be addressed). They were concerned that the day-to-day user and decision maker was getting caught up in the details new features and losing site of the big objectives that needed to be achieved within the timeframe. We heard another client call this being DRUNK ON AGILE.

                                          What we had to do was conciously help the customer focus on what the overall objectives were and how the stories would help achieve that. It was a means of helping the customer prioritize what she needed each iteration. She still could change stories each iteration, but it helped make sure her interestes and managements interests were aligned.



                                          Ron Jeffries <ronjeffries@...> wrote:
                                          On Thursday, October 13, 2005, at 3:23:18 PM, Dave McMunn wrote:

                                          > One way we have found that helps prevent scope creep is to have
                                          > the client essentially put a value on each story. That means first
                                          > clearly defining the release objectives up front. Then, when you
                                          > define the story and the developers establish the cost, the
                                          > business establishes quantifies the benefit (based well it
                                          > achieves the objectives). This was done indepent of the cost. It
                                          > helped the customer tremendously to get out of the emotion of what
                                          > they desired and really focus on how it moved the application
                                          > forward to achieving the business objectives.

                                          Dave, I'd have said at first glance that this notion is somewhat
                                          counter to the whole agile notion of embracing change. How would you
                                          relate this idea to that one?

                                          Ron Jeffries
                                          www.XProgramming.com
                                          Hope is not a strategy. -- Michael Henos



                                          To Post a message, send it to: extremeprogramming@...

                                          To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                          ad-free courtesy of objectmentor.com
                                          Yahoo! Groups Links










                                          ---------------------------------
                                          Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

                                          [Non-text portions of this message have been removed]
                                        • Ron Jeffries
                                          ... Yes, I see what you mean. It would seem that the buyer needs to make it clear to the detail customer that the point is to get the best possible product
                                          Message 20 of 24 , Oct 14, 2005
                                            On Friday, October 14, 2005, at 1:50:42 PM, Dave McMunn wrote:

                                            > I guess in my experience there can two types of customer. One
                                            > customer is the buyer who is funding the project. That person
                                            > doesn't necessarily get into the details, but they are responsible
                                            > for making sure that certain objectives are met in a timetable.
                                            > The other customer is the actual how sometimes is more concerned
                                            > about nice to have features than the bigger objectives behind
                                            > management's release.

                                            Yes, I see what you mean. It would seem that the "buyer" needs to
                                            make it clear to the detail customer that the point is to get the
                                            best possible product by a date, within a budget. Sometimes people
                                            do lose sight of that. In fact, the second C3 customer lost sight of
                                            that and even said, after the project closed down, something like "I
                                            didn't realize that we were actually supposed to release it."

                                            A Release Plan, such as described in /Extreme Programming
                                            Installed/, (first edition), or in /Planning Extreme Programming/ or
                                            other sources, helps to focus the team on release. Yet I have seen
                                            that not be sufficient.

                                            Similarly, a burn-down chart (or even burn up) would suffice, one
                                            might think. There's a big red date on the chart, a big line where
                                            the maximum expenditure is. Yet I've seen that not be sufficient
                                            also.

                                            This kind of situation can be very frustrating for the team, because
                                            some of them believe that the sky will fall if they don't ship, and
                                            others appear not to believe it, or not to care.

                                            > On a recent example, we had the day-to-day customer involve with
                                            > the team. After each iteration she would review the progress to
                                            > date and frequently come up with new stories that would enhance
                                            > the application to achieve the specific process that was being
                                            > worked upon. The concern from Management was that while the
                                            > application may be improved in the details, they needed to acheive
                                            > some higher level goals (other major components needed to be
                                            > addressed). They were concerned that the day-to-day user and
                                            > decision maker was getting caught up in the details new features
                                            > and losing site of the big objectives that needed to be achieved
                                            > within the timeframe. We heard another client call this being
                                            > DRUNK ON AGILE.

                                            What did "Management" do about this? I inquire because it seems to
                                            me that if the detail customer was wandering, it would be evidence
                                            of, um, less than perfect understanding of what her boss wanted.

                                            > What we had to do was conciously help the customer focus on what
                                            > the overall objectives were and how the stories would help achieve
                                            > that. It was a means of helping the customer prioritize what she
                                            > needed each iteration. She still could change stories each
                                            > iteration, but it helped make sure her interestes and managements
                                            > interests were aligned.

                                            Yes, that's certainly what needs to happen. Sounds like you did good
                                            stuff. What approaches did you take to helping her focus?

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Get over it. -- The Eagles
                                          • Steven Gordon
                                            Dave, Thanks for a clear example of what I have been trying to say. Drunk on Agile is a good term for it. While you can remind this direct customer of the
                                            Message 21 of 24 , Oct 14, 2005
                                              Dave,
                                              Thanks for a clear example of what I have been trying to say. "Drunk on
                                              Agile" is a good term for it.
                                              While you can remind this direct customer of the corporate objectives,
                                              discipline on the part of the development team is no substitute for clear
                                              communication between the direct customer and their management.

                                              On 10/14/05, Dave McMunn <mcmunn05@...> wrote:
                                              >
                                              > I guess in my experience there can two types of customer. One customer is
                                              > the buyer who is funding the project. That person doesn't necessarily get
                                              > into the details, but they are responsible for making sure that certain
                                              > objectives are met in a timetable. The other customer is the actual how
                                              > sometimes is more concerned about nice to have features than the bigger
                                              > objectives behind management's release.
                                              >
                                              > On a recent example, we had the day-to-day customer involve with the team.
                                              > After each iteration she would review the progress to date and frequently
                                              > come up with new stories that would enhance the application to achieve the
                                              > specific process that was being worked upon. The concern from Management was
                                              > that while the application may be improved in the details, they needed to
                                              > acheive some higher level goals (other major components needed to be
                                              > addressed). They were concerned that the day-to-day user and decision maker
                                              > was getting caught up in the details new features and losing site of the big
                                              > objectives that needed to be achieved within the timeframe. We heard another
                                              > client call this being DRUNK ON AGILE.
                                              >
                                              > What we had to do was conciously help the customer focus on what the
                                              > overall objectives were and how the stories would help achieve that. It was
                                              > a means of helping the customer prioritize what she needed each iteration.
                                              > She still could change stories each iteration, but it helped make sure her
                                              > interestes and managements interests were aligned.
                                              >
                                              >


                                              [Non-text portions of this message have been removed]
                                            • Dave McMunn
                                              Ron Jeffries wrote: ... At the start, I believe management and the customer were on the same page, it was after time that the
                                              Message 22 of 24 , Oct 14, 2005
                                                Ron Jeffries <ronjeffries@...> wrote:
                                                On Friday, October 14, 2005, at 1:50:42 PM, Dave McMunn wrote:

                                                >> On a recent example, we had the day-to-day customer involve with
                                                >> the team. After each iteration she would review the progress to
                                                >> date and frequently come up with new stories that would enhance
                                                >> the application to achieve the specific process that was being
                                                >> worked upon. The concern from Management was that while the
                                                >> application may be improved in the details, they needed to acheive
                                                >> some higher level goals (other major components needed to be
                                                >> addressed). They were concerned that the day-to-day user and
                                                >> decision maker was getting caught up in the details new features
                                                >>and losing site of the big objectives that needed to be achieved
                                                >> within the timeframe. We heard another client call this being
                                                >> DRUNK ON AGILE.

                                                >What did "Management" do about this? I inquire because it seems to
                                                >me that if the detail customer was wandering, it would be evidence
                                                >of, um, less than perfect understanding of what her boss wanted.



                                                At the start, I believe management and the customer were on the same page, it was after time that the customer began to wonder. So part of the power of agile is exactly this, management could recognize the situation early. The actions taken were management reiterated the focus on the objecitives to make sure every one was clear what needed to happen. To then help make that focus more tangible, the backlog of stories was evaluated against the objectives and prioritise in terms of achieving the objective (we used 1-4, it was easy and worked). As importantly, the exercise gave her a means to express to her management how they were going to meet the project objectives while avoiding "scope creep." After the initial time, as each new story was identified it received two scores, a cost (size) and value. This helped to focus the whole team on the business objectives and to bring the team together.



                                                The other thing that would have helped tremendously (but we did not do it on this) would have been to have a short release cycle. The release for this project was too long -- 6 months.



                                                >> What we had to do was conciously help the customer focus on what
                                                >> the overall objectives were and how the stories would help achieve
                                                >> that. It was a means of helping the customer prioritize what she
                                                >> needed each iteration. She still could change stories each
                                                >> iteration, but it helped make sure her interestes and managements
                                                >> interests were aligned.

                                                Yes, that's certainly what needs to happen. Sounds like you did good
                                                stuff. What approaches did you take to helping her focus?

                                                Ron Jeffries
                                                www.XProgramming.com
                                                Get over it. -- The Eagles



                                                To Post a message, send it to: extremeprogramming@...

                                                To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

                                                ad-free courtesy of objectmentor.com
                                                Yahoo! Groups Links












                                                ---------------------------------
                                                Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

                                                [Non-text portions of this message have been removed]
                                              • Keith Braithwaite
                                                ... They ended up doing that, yes. No-one else would provide direction as to what should get done text so the team just chose stuff. This was a late symptom,
                                                Message 23 of 24 , Oct 14, 2005
                                                  --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                                  <ronjeffries@X...> wrote:
                                                  >
                                                  > Interesting ... it seems odd to blame development for what is so
                                                  > clearly the business people's problem. It makes me think that
                                                  > perhaps the development team was deciding which stories to do in
                                                  > each iteration. Was that the case?
                                                  They ended up doing that, yes. No-one else would provide direction as
                                                  to what should get done text so the team just chose stuff. This was a
                                                  late symptom, not an early cause, however.

                                                  As to blaming development for business problems, that was a lot easier
                                                  than fixing the business problems. Plus the developers weren't doing
                                                  themsleves any favours by adopting over-engineered solutions that
                                                  caused estimates that even the least tech savvy account manager could
                                                  see were grossly overweight. This made them a soft target.

                                                  >
                                                  > > This was fixed almost instantaneously by requiring the proxy customers
                                                  > > to submit purchace orders for the cost of development of their
                                                  > > stories. This wasn't an ISV but a service company, so all these PO's
                                                  > > represented was the company moving money from one pocket to
                                                  > > another--but they focussed attention.
                                                  >
                                                  > An elegant step. Yet I wonder, given that there was less capacity
                                                  > than there was desire, why they didn't still fight over whose PO
                                                  > would be accepted ...
                                                  Well, when the last slot in the plan could be filled by PO #123 that
                                                  is going to cost GBP 100,000 and is projected to bring in GBP 150,000
                                                  vs PO #456 that will cost GBP 75,000 but is projected to bring in GBP
                                                  200,000 then there needs to be a really, exceptionally good reason not
                                                  to choose #456. In the absence of that, the choice is easy.


                                                  > I'm a little surprised that it changed things,
                                                  > in that PO amount = K*story estimate.
                                                  In this case the business managers had continually complained that the
                                                  "craft units" (in which estimates were quoted and velocity measured)
                                                  were meaningless. And so there was endless room for argument at
                                                  planning about why such and so story was "20" and not "15" or "25".
                                                  And couldn't it be 15 just this once so that this super important
                                                  thing could make it into the plan. For some reason, much larger
                                                  figures quoted in GBPs (even though they are exactly craft units *
                                                  GBP/unit) seemed not to cause that. Go figure.

                                                  >
                                                  > But ... to summarize what I don't understand:
                                                  >
                                                  > Before:
                                                  >
                                                  > team can do N points per iteration;
                                                  > multiple customers with conflicting needs;
                                                  > team oversubscribed;
                                                  > story cost in points or hours;
                                                  > ==> chaos and anger;
                                                  >
                                                  > After:
                                                  >
                                                  > team can do M dollars per iteration, K*N;
                                                  > multiple customers with conflicting needs;
                                                  > team oversubscribed;
                                                  > story cost in fake dollars;
                                                  > ==> sweetness and light;
                                                  >
                                                  > Though small changes can make big differences, I'm wondering what
                                                  > happened here, whether there was anything else going on that also
                                                  > mattered.
                                                  Looking back, the important change was kind of hidden, I think.
                                                  There's the GBP magic above, but also this:

                                                  Before-- cost of stories known, but value of stories unknown,
                                                  and/because nobody cares that's it's unknown
                                                  After-- cost of stories known, and you better had care about the value
                                                  in order to justfy the cost.

                                                  I was to run an estimating workshop for the business types. The
                                                  intention was to use a series of graded exercises: first, estimate my
                                                  height. Then, the dry weight of my motorcycle. There was a large
                                                  contingent of bikers there, so I could finagle the groups for the
                                                  exercices to bring out some points about expertise. Everyone is an
                                                  expert in how tall humans are, I supposed that most non-bikers would
                                                  have no clue about how heavy a bike would be.

                                                  Then estimate the revenue from a piece of work already in production,
                                                  and compare against the actual. Then estimate a piece of new work. My
                                                  plan collapsed at phase three, when I discovered that although the
                                                  "audit" accounting was woring just fine, so they could show that the
                                                  money received from customers each month was the right amout, the
                                                  "management" accouting was non-existant and no-one knew exactly where
                                                  any of the money came from, and so nor did they know exactly what any
                                                  existing functionality was earning. Scary stuff.

                                                  Since no-one had any way of working back to see if their revenue
                                                  projections had been accurate, those projections tended to be random
                                                  numbers, everyone knew that and so they were ignored. Unable to reason
                                                  about outputs, the group fell to squabbling aboubt inputs.

                                                  One of the sales guys there came up with an interesting metaphor. The
                                                  company had for a long time, he said, been on "visual flight rules".
                                                  Business was good, revenues were strong, so all they had to do was
                                                  look out the window and see that the ground was far away, the
                                                  landmarks in roughly the right place. But then business conditions
                                                  changed, the fog came down and they had to switch to "instrument
                                                  flight rules". Unfortunately, it turned out that a lot of the
                                                  instruments didn't work; and those that did, no-one knew what they meant.

                                                  >
                                                  > > I don't understand which bit of this was a reduction in agility.
                                                  >
                                                  > I don't think anyone has said that any of it was.
                                                  I think I misunderstood your prompt to Dave.

                                                  Keith
                                                • Ron Jeffries
                                                  ... Great story, Keith, thanks! Ron Jeffries www.XProgramming.com You don t want to sell me waterfall. You want to go home and rethink your life.
                                                  Message 24 of 24 , Oct 14, 2005
                                                    On Friday, October 14, 2005, at 6:28:27 PM, Keith Braithwaite wrote:

                                                    > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                                    > <ronjeffries@X...> wrote:
                                                    >>
                                                    >> Interesting ... it seems odd to blame development for what is so
                                                    >> clearly the business people's problem. It makes me think that
                                                    >> perhaps the development team was deciding which stories to do in
                                                    >> each iteration. Was that the case?
                                                    > They ended up doing that, yes. No-one else would provide direction as
                                                    > to what should get done text so the team just chose stuff. This was a
                                                    > late symptom, not an early cause, however.

                                                    Great story, Keith, thanks!

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    You don't want to sell me waterfall.
                                                    You want to go home and rethink your life.
                                                  Your message has been successfully submitted and would be delivered to recipients shortly.