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

Scope Creep

Expand Messages
  • Mary Poppendieck
    During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about scope creep . Personally, I do not
    Message 1 of 14 , Apr 11 6:00 AM

      During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about ‘scope creep’.

       

      Personally, I do not believe in scope creep, and when viewed from they eyes of a customer, ‘scope creep’ can come across as a condescending term.  I find it difficult to use the word ‘scope creep’ in front of a customer in a way which does not sound pejorative. 

       

      Customers have needs that they understand with more or less clarity.  They have a budget and a timeframe in which they wish to get those needs satisfied.  In the process of satisfying those needs, the details become clarified and things change.   Thus the original understanding of what was to be done changes.  This is a normal, natural pattern in software development, but when it is labeled ‘scope creep’ it is thought of as ‘bad’. 

       

      Software development is a series of try-it-test-it-fix it cycles that span as much of the system as possible.  These cycles improve understanding of what it takes to achieve the business mission or objective.  As understanding improves, it is useful to add ideas to the list of things to be done. There is nothing wrong with a long backlog list – it gathers together everyone’s good ideas.    

       

      The game to be played is to have a clear understanding that not everything on the backlog is expected to be completed, and where the line is drawn depends on when we run out of time and other resources.  The term ‘scope creep’ focuses people on the length of the list, which is irrelevant, instead of the necessity of drawing the line part way down the list, no matter how long it is.  It is a waste of time to worry about shortening the list, what we need to worry about is how to stop working when the justification and or time for the work is used up.  Any method which helps people to draw this line is useful.  But it is not useful to focus on the movement of items above and below the line as learning increases.  

       

      Perhaps we might worry about ‘mission creep’, but it would seem to me that with Scrum there is no such thing as scope creep, because there is no attempt to fix scope to begin with, so there is nothing for scope to creep away from.   

       

      Mary Poppendieck

      www.poppendieck.com

      Author of

      Lean Software Development: An Agile Toolkit

       

    • Bryan Zarnett
      My view is that scope creep exists only when change control or the management of requirements does not occur. My view is, that if in my current sprint, you
      Message 2 of 14 , Apr 11 7:02 AM

        During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about ‘scope creep’.

         

        Personally, I do not believe in scope creep, and when viewed from they eyes of a customer, ‘scope creep’ can come across as a condescending term.  I find it difficult to use the word ‘scope creep’ in front of a customer in a way which does not sound pejorative. 

         

        Customers have needs that they understand with more or less clarity.  They have a budget and a timeframe in which they wish to get those needs satisfied.  In the process of satisfying those needs, the details become clarified and things change.   Thus the original understanding of what was to be done changes.  This is a normal, natural pattern in software development, but when it is labeled ‘scope creep’ it is thought of as ‘bad’. 

         

        Software development is a series of try-it-test-it-fix it cycles that span as much of the system as possible.  These cycles improve understanding of what it takes to achieve the business mission or objective.  As understanding improves, it is useful to add ideas to the list of things to be done. There is nothing wrong with a long backlog list – it gathers together everyone’s good ideas.    

         

        The game to be played is to have a clear understanding that not everything on the backlog is expected to be completed, and where the line is drawn depends on when we run out of time and other resources.  The term ‘scope creep’ focuses people on the length of the list, which is irrelevant, instead of the necessity of drawing the line part way down the list, no matter how long it is.  It is a waste of time to worry about shortening the list, what we need to worry about is how to stop working when the justification and or time for the work is used up.  Any method which helps people to draw this line is useful.  But it is not useful to focus on the movement of items above and below the line as learning increases.  

         

        Perhaps we might worry about ‘mission creep’, but it would seem to me that with Scrum there is no such thing as scope creep, because there is no attempt to fix scope to begin with, so there is nothing for scope to creep away from.   

         

        Mary Poppendieck

        www.poppendieck.com

        Author of

        Lean Software Development: An Agile Toolkit

         



        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      • Mike Cohn
        Great points, Mary. But one of your comments raises a question: if the length of the list is irrelevant (as you say in the next to last paragraph, and which I
        Message 3 of 14 , Apr 11 7:44 AM

          Great points, Mary. But one of your comments raises a question: if the length of the list is irrelevant (as you say in the next to last paragraph, and which I agree with) then doesn’t that mean a build up chart is irrelevant? Yes it shows a line going up instead of down but the introduction of additional lines showing the scope at points in time must now also be irrelevant, I’d think.

           

          -Mike

           

          -----Original Message-----
          From: Mary Poppendieck [mailto:mary@...]
          Sent: Friday, April 11, 2003 7:00 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Scope Creep

           

          During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about ‘scope creep’.

           

          Personally, I do not believe in scope creep, and when viewed from they eyes of a customer, ‘scope creep’ can come across as a condescending term.  I find it difficult to use the word ‘scope creep’ in front of a customer in a way which does not sound pejorative. 

           

          Customers have needs that they understand with more or less clarity.  They have a budget and a timeframe in which they wish to get those needs satisfied.  In the process of satisfying those needs, the details become clarified and things change.   Thus the original understanding of what was to be done changes.  This is a normal, natural pattern in software development, but when it is labeled ‘scope creep’ it is thought of as ‘bad’. 

           

          Software development is a series of try-it-test-it-fix it cycles that span as much of the system as possible.  These cycles improve understanding of what it takes to achieve the business mission or objective.  As understanding improves, it is useful to add ideas to the list of things to be done. There is nothing wrong with a long backlog list – it gathers together everyone’s good ideas.    

           

          The game to be played is to have a clear understanding that not everything on the backlog is expected to be completed, and where the line is drawn depends on when we run out of time and other resources.  The term ‘scope creep’ focuses people on the length of the list, which is irrelevant, instead of the necessity of drawing the line part way down the list, no matter how long it is.  It is a waste of time to worry about shortening the list, what we need to worry about is how to stop working when the justification and or time for the work is used up.  Any method which helps people to draw this line is useful.  But it is not useful to focus on the movement of items above and below the line as learning increases.  

           

          Perhaps we might worry about ‘mission creep’, but it would seem to me that with Scrum there is no such thing as scope creep, because there is no attempt to fix scope to begin with, so there is nothing for scope to creep away from.   

           

          Mary Poppendieck

          www.poppendieck.com

          Author of

          Lean Software Development: An Agile Toolkit

           



          To Post a message, send it to:   scrumdevelopment@...
          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


          Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • Lowell Lindstrom
          Mary - I couldn t agree more and you stated it very clearly! I think mission creep has the same weaknesses that you describe, but agree that if the mission is
          Message 4 of 14 , Apr 11 8:00 AM
            Message
            Mary -
             
            I couldn't agree more and you stated it very clearly!
             
            I think mission creep has the same weaknesses that you describe, but agree that if the mission is moving as much as the scope, then heavy investment in implementing the project is questionable.
             
            Scope creep articulates a change to the assumptions on which a project commitment was made.  It expresses it in a way that puts responsibility on the customer, as you describe.  Given all the variables involved and the clarity that comes as the project progresses, it is often impossible to know if the scope has creeped or if the buffer available to handle the additional "scope" that clarity has identifed has been exhausted due to an inefficiency elsewhere.
             
            Business most always must make commitments on a set of scope at some future point in time.  There does need to be a language through which to whole team can communicate when these commitments are at risk.  The cahrt, of course, illustrates it nicely.  Without identification of causes, improvement is difficult at best.  "Creep" is probably the condensing part of the phrase that needs to be revised.  Scope will, at times, expand, as will the time required to complete a story or task relative to its estimate.   A better term is not coming to mind at the moment.  "Expansion" is what is my head.
             
            Lowell

            ====================
            Lowell Lindstrom
            Business Coach

            Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
            lindstrom@...

            -----Original Message-----
            From: Mary Poppendieck [mailto:mary@...]
            Sent: Friday, April 11, 2003 8:00 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Scope Creep

            During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about 'scope creep'.

             

            Personally, I do not believe in scope creep, and when viewed from they eyes of a customer, 'scope creep' can come across as a condescending term.  I find it difficult to use the word 'scope creep' in front of a customer in a way which does not sound pejorative. 

             

            Customers have needs that they understand with more or less clarity.  They have a budget and a timeframe in which they wish to get those needs satisfied.  In the process of satisfying those needs, the details become clarified and things change.   Thus the original understanding of what was to be done changes.  This is a normal, natural pattern in software development, but when it is labeled 'scope creep' it is thought of as 'bad'. 

             

            Software development is a series of try-it-test-it-fix it cycles that span as much of the system as possible.  These cycles improve understanding of what it takes to achieve the business mission or objective.  As understanding improves, it is useful to add ideas to the list of things to be done. There is nothing wrong with a long backlog list - it gathers together everyone's good ideas.    

             

            The game to be played is to have a clear understanding that not everything on the backlog is expected to be completed, and where the line is drawn depends on when we run out of time and other resources.  The term 'scope creep' focuses people on the length of the list, which is irrelevant, instead of the necessity of drawing the line part way down the list, no matter how long it is.  It is a waste of time to worry about shortening the list, what we need to worry about is how to stop working when the justification and or time for the work is used up.  Any method which helps people to draw this line is useful.  But it is not useful to focus on the movement of items above and below the line as learning increases.  

             

            Perhaps we might worry about 'mission creep', but it would seem to me that with Scrum there is no such thing as scope creep, because there is no attempt to fix scope to begin with, so there is nothing for scope to creep away from.   

             

            Mary Poppendieck

            www.poppendieck.com

            Author of

            Lean Software Development: An Agile Toolkit

             



            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          • Hal Macomber
            I share Mary s view. Customers generally do the best they can do describing what it is that will address the concerns that they have. We see the same things
            Message 5 of 14 , Apr 11 8:34 AM

              I share Mary's view.  Customers generally do the best they can do describing what it is that will address the concerns that they have.  We see the same things in defense systems and construction projects as you describe in software.  The situation in construction is often exagerated by the fact that so many customers have never been a customer for a construction project before and won't be after.  It is the project team's responsibility to understand at the root level why the project matters to the customer.  Only at this level are we able to co-invent with the customer a set of conditions of satisfaction (COS) that address those concerns.  To call changes to those COS as the project gets underway "scope creep" both misunderstands the nature of projects and may point to a poor job of the team in understanding concerns.

               Mary Poppendieck <mary@...> wrote:

              During the discussion of burn-up charts, now renamed build-up charts, I have encountered several people talking about �scope creep�.

               

              Personally, I do not believe in scope creep, and when viewed from they eyes of a customer, �scope creep� can come across as a condescending term.  I find it difficult to use the word �scope creep� in front of a customer in a way which does not sound pejorative. 

               

              Customers have needs that they understand with more or less clarity.  They have a budget and a timeframe in which they wish to get those needs satisfied.  In the process of satisfying those needs, the details become clarified and things change.   Thus the original understanding of what was to be done changes.  This is a normal, natural pattern in software development, but when it is labeled �scope creep� it is thought of as �bad�. 

               

              Software development is a series of try-it-test-it-fix it cycles that span as much of the system as possible.  These cycles improve understanding of what it takes to achieve the business mission or objective.  As understanding improves, it is useful to add ideas to the list of things to be done. There is nothing wrong with a long backlog list � it gathers together everyone�s good ideas.    

               

              The game to be played is to have a clear understanding that not everything on the backlog is expected to be completed, and where the line is drawn depends on when we run out of time and other resources.  The term �scope creep� focuses people on the length of the list, which is irrelevant, instead of the necessity of drawing the line part way down the list, no matter how long it is.  It is a waste of time to worry about shortening the list, what we need to worry about is how to stop working when the justification and or time for the work is used up.  Any method which helps people to draw this line is useful.  But it is not useful to focus on the movement of items above and below the line as learning increases.  

               

              Perhaps we might worry about �mission creep�, but it would seem to me that with Scrum there is no such thing as scope creep, because there is no attempt to fix scope to begin with, so there is nothing for scope to creep away from.   

               

              Mary Poppendieck

              www.poppendieck.com

              Author of

              Lean Software Development: An Agile Toolkit

               



              To Post a message, send it to:   scrumdevelopment@...
              To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


              Subscribe to Reforming Project Management
              Enter your email address:

              Don't miss a posting! Forward to a friend.
            • Lowell Lindstrom
              I think you are reinforcing Mary s point. You have even made it worse with the penalty analogy ** Business needs will change, sometimes within a Sprint,
              Message 6 of 14 , Apr 11 9:06 AM
                I think you are reinforcing Mary's point. You have even made it worse with
                the "penalty" analogy ** Business needs will change, sometimes within a
                Sprint, certainly so if they are a month long. No one should be penalized
                for that. Change control can make sure that we do not incur the disruption
                cost unnecessarily, but changing the contents of a sprint should be
                expressed as expensive, not wrong or as result of someone failing, which
                your description implies to me. In a way, that would build root cause
                analysis into the process, masking an honest understanding of why we have a
                disconnect between what we selected for the Sprint and what the business now
                requires.

                ** I've posted before that I don't think Scrum reflects Rugby much. But it
                is not clear to me that it is intended to be a metaphor of Rugby, rather
                than just a borrowed term.


                Lowell
                ====================
                Lowell Lindstrom
                Business Coach
                Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
                lindstrom@...



                >
                > My view is that "scope creep" exists only when 'change
                > control' or the management of requirements does not occur. My
                > view is, that if in my current sprint, you ask we to do
                > something that is not in my backlog for the sprint and I do
                > it (or am forced into it), that is scope creep. If it gets
                > added to the product backlog, that is not "scope creep" cause
                > its controlled.
                >
                > In Scrum, I guess this would be consider being "offside".
                > Although the term does not fit in the exact Rugby notation,
                > the concept is similar where, the end result is a penalty
                > that occurs when the offence takes place. In this
                > circumstance, the team mate who accepts the change in scope
                > for the sprint would be offside in the sprint causing
                > problems. (bad description, sorry).
                >
                > Bryan
                >
                >
                > On Friday, April 11, 2003, at 09:00AM, Mary Poppendieck
                > <mary@...> wrote:
                >
                > >
                > ><<Original Attached>>
                > ------------------------ Yahoo! Groups Sponsor
                > ---------------------~--> Make Money Online Auctions! Make
                > $500.00 or We Will Give You Thirty Dollars for Trying!
                > http://us.click.yahoo.com/yMx78A/fNtFAA/i5gGAA> /9EfwlB/TM
                >
                >
                > --------------------------------------------------------------
                > -------~->
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >
              • Phil Goodwin
                ... The lines represent the points at which the scope is considered to be sufficient for the next release (or release event such as version change) to occur.
                Message 7 of 14 , Apr 11 11:09 AM
                  Mike Cohn wrote:

                  Great points, Mary. But one of your comments raises a question: if the length of the list is irrelevant (as you say in the next to last paragraph, and which I agree with) then doesn’t that mean a build up chart is irrelevant? Yes it shows a line going up instead of down but the introduction of additional lines showing the scope at points in time must now also be irrelevant, I’d think.

                  The lines represent the points at which the scope is considered to be sufficient for the next release (or release event such as version change) to occur. If those lines (representing the total amount of work in the budget for the release) move upward as the project progresses then there is feature creep -- budget discipline is not being excercised for the release event. If the feature creep rises faster than the velocity of the project then the release event will never occur. There will always be scope that could be added to the project, so there is always the potential for the scope to creep. At some point the potential scope for the project will not hold more value than the cost of realizing that scope and the project should end. Different projects care different amounts about their release events. The value of a build up chart varies with the value of the release event that it tracks (plus the value of tracking velocity).

                  -- 
                  -----------------------------------------------------------------------
                  Phil Goodwin, Java Software, Sun Microsystems, 408.276.7090, or x17090
                  
                  For a bowl of water give a goodly meal;
                  For a kindly greeting bow thou down with zeal;
                  For a simple penny pay thou back with gold;
                  If thy life be rescued, life do not withhold.
                  Thus the words and actions of the wise regard;
                  Every little service tenfold they reward.
                  But the truly noble know all men as one,
                  And return with gladness good for evil done.
                  - Shamal Bhatt
                  

                • Phil Goodwin
                  If sprints have a limited time span and a limited velocity then the magnitude of the scope vector cannot change, although the direction of the unrealized scope
                  Message 8 of 14 , Apr 11 11:30 AM
                    If sprints have a limited time span and a limited velocity then the magnitude of the scope vector cannot change, although the direction of the unrealized scope vector certainly can. Scope creep happens when one component of the overall unrealized scope vector is increased without a compensating decrease in some other component. The only problem I have with using pejorative labels for this sort of delusional thinking is that history has shown pejorative labels to be a poor means of changing delusional thinking, which I think is the goal. It's not that changing planned scope is wrong, it's that increasing planned scope without increasing either planned time or actual velocity is wrong. That is to say "wrong" in the sense that the conclusion will not match reality, not "wrong" in the moral sense, although that could be argued.

                    Lowell Lindstrom wrote:
                    I think you are reinforcing Mary's point.  You have even made it worse with
                    the "penalty" analogy **   Business needs will change, sometimes within a
                    Sprint, certainly so if they are a month long.  No one should be penalized
                    for that.  Change control can make sure that we do not incur the disruption
                    cost unnecessarily, but changing the contents of a sprint should be
                    expressed as expensive, not wrong or as result of someone failing, which
                    your description implies to me.  In a way, that would build root cause
                    analysis into the process, masking an honest understanding of why we have a
                    disconnect between what we selected for the Sprint and what the business now
                    requires.
                    
                    ** I've posted before that I don't think Scrum reflects Rugby much.  But it
                    is not clear to me that it is intended to be a metaphor of Rugby, rather
                    than just a borrowed term.
                    
                    
                    Lowell
                    ====================
                    Lowell Lindstrom
                    Business Coach
                    Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
                    lindstrom@...
                    
                    
                    
                      
                    My view is that "scope creep" exists only when 'change 
                    control' or the management of requirements does not occur. My 
                    view is, that if in my current sprint, you ask we to do 
                    something that is not in my backlog for the sprint and I do 
                    it (or am forced into it), that is scope creep. If it gets 
                    added to the product backlog, that is not "scope creep" cause 
                    its controlled.
                    
                    In Scrum, I guess this would be consider being "offside". 
                    Although the term does not fit in the exact Rugby notation, 
                    the concept is similar where, the end result is a penalty 
                    that occurs when the offence takes place. In this 
                    circumstance, the team mate who accepts the change in scope 
                    for the sprint would be offside in the sprint causing 
                    problems. (bad description, sorry).
                    
                    Bryan
                    
                     
                    On Friday, April 11, 2003, at 09:00AM, Mary Poppendieck 
                    <mary@...> wrote:
                    
                        
                    <<Original Attached>>
                          
                    ------------------------ Yahoo! Groups Sponsor 
                    ---------------------~--> Make Money Online Auctions! Make 
                    $500.00 or We Will Give You Thirty Dollars for Trying! 
                    http://us.click.yahoo.com/yMx78A/fNtFAA/i5gGAA> /9EfwlB/TM
                    
                    
                    --------------------------------------------------------------
                    -------~->
                    
                    To Post a message, send it to:   scrumdevelopment@...
                    To Unsubscribe, send a blank message to: 
                    scrumdevelopment-unsubscribe@... 
                    
                    Your use of Yahoo! Groups is subject to 
                    http://docs.yahoo.com/info/terms/ 
                    
                    
                        
                    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
                    Make Money Online Auctions! Make $500.00 or We Will Give You Thirty Dollars for Trying!
                    http://us.click.yahoo.com/yMx78A/fNtFAA/i5gGAA/9EfwlB/TM
                    ---------------------------------------------------------------------~->
                    
                    To Post a message, send it to:   scrumdevelopment@...
                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@... 
                    
                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
                    
                    
                      

                    -- 
                    -----------------------------------------------------------------------
                    Phil Goodwin, Java Software, Sun Microsystems, 408.276.7090, or x17090
                    
                    For a bowl of water give a goodly meal;
                    For a kindly greeting bow thou down with zeal;
                    For a simple penny pay thou back with gold;
                    If thy life be rescued, life do not withhold.
                    Thus the words and actions of the wise regard;
                    Every little service tenfold they reward.
                    But the truly noble know all men as one,
                    And return with gladness good for evil done.
                    - Shamal Bhatt
                    

                  • Russ Rufer
                    Mike, The way scope is tracked on the Build Up Chart allows the chart to be extended over time (say as a poster on a wall) without redrawing the chart. Some
                    Message 9 of 14 , Apr 11 12:08 PM
                      Mike,

                      The way scope is tracked on the Build Up Chart allows the chart to be
                      extended over time (say as a poster on a wall) without redrawing the chart.

                      Some history of scope revision can also be useful to explain changes in
                      projected target date. For example, if Feature X is removed from your
                      backlog because the large customer requesting it decided on another
                      vendor, that history would expose why the team was suddenly ahead of
                      their schedule for earlier estimates.

                      If you want to hide (the complexity of) issues like that, and are
                      redrawing your chart every time you want to update it, then a single bar
                      indicating scope at a point in time would suffice.

                      Key, though, is separating scope revision from velocity. No one has
                      addressed my difficulties with Burn Down Charts yet (as expressed in
                      archive Messages 1149 and 1154) which led us to look at alternatives.

                      Consider a project that had a series of tasks removed from the backlog,
                      as in the above example. Without knowing additional details, the most
                      reasonable interpretation of a Burn Down Chart would be that the team
                      velocity had accelerated, and new target date predictions would be based
                      on that assumption. These new predictions would be flawed unless tasks
                      continued to be removed at a blistering pace, since actual velocity
                      probably didn't change. Build Up Charts expose the true velocity
                      without regard to scope revision.

                      - Russ
                      Silicon Valley Patterns Group


                      Mike Cohn wrote:
                      > Great points, Mary. But one of your comments raises a question: if the
                      > length of the list is irrelevant (as you say in the next to last
                      > paragraph, and which I agree with) then doesn’t that mean a build up
                      > chart is irrelevant? Yes it shows a line going up instead of down but
                      > the introduction of additional lines showing the scope at points in time
                      > must now also be irrelevant, I’d think.
                      >
                      >
                      >
                      > -Mike
                    • Michael Feathers
                      Hello Mary, I agree. When a developer talks about scope creep it is based upon their guess at what the scope would be, but that is really the customer s
                      Message 10 of 14 , Apr 11 12:47 PM
                        Hello Mary,

                        I agree. When a developer talks about scope creep it is based
                        upon their guess at what the scope would be, but that is really
                        the customer's concern. But, when someone outside of the
                        customer/team realm talks about scope creep, perhaps some higher
                        level manager, it indicates that there may be disconnect
                        between organizational goals for the system and the goals that
                        the customer drove towards. Is that "mission creep" or
                        something different?

                        Michael Feathers
                        www.objectmentor.com


                        MP> During the discussion of burn-up charts, now renamed build-up charts, I
                        MP> have encountered several people talking about 'scope creep'.

                        MP> Personally, I do not believe in scope creep, and when viewed from they
                        MP> eyes of a customer, 'scope creep' can come across as a condescending
                        MP> term. I find it difficult to use the word 'scope creep' in front of a
                        MP> customer in a way which does not sound pejorative.



                        MP> Customers have needs that they understand with more or less clarity.
                        MP> They have a budget and a timeframe in which they wish to get those needs
                        MP> satisfied. In the process of satisfying those needs, the details become
                        MP> clarified and things change. Thus the original understanding of what
                        MP> was to be done changes. This is a normal, natural pattern in software
                        MP> development, but when it is labeled 'scope creep' it is thought of as
                        MP> 'bad'.



                        MP> Software development is a series of try-it-test-it-fix it cycles that
                        MP> span as much of the system as possible. These cycles improve
                        MP> understanding of what it takes to achieve the business mission or
                        MP> objective. As understanding improves, it is useful to add ideas to the
                        MP> list of things to be done. There is nothing wrong with a long backlog
                        MP> list - it gathers together everyone's good ideas.



                        MP> The game to be played is to have a clear understanding that not
                        MP> everything on the backlog is expected to be completed, and where the
                        MP> line is drawn depends on when we run out of time and other resources.
                        MP> The term 'scope creep' focuses people on the length of the list, which
                        MP> is irrelevant, instead of the necessity of drawing the line part way
                        MP> down the list, no matter how long it is. It is a waste of time to worry
                        MP> about shortening the list, what we need to worry about is how to stop
                        MP> working when the justification and or time for the work is used up. Any
                        MP> method which helps people to draw this line is useful. But it is not
                        MP> useful to focus on the movement of items above and below the line as
                        MP> learning increases.

                        MP> Perhaps we might worry about 'mission creep', but it would seem to me
                        MP> that with Scrum there is no such thing as scope creep, because there is
                        MP> no attempt to fix scope to begin with, so there is nothing for scope to
                        MP> creep away from.
                      • Mary Poppendieck
                        I like your idea of using the word Expansion instead of Creep , but even then, it seems to indicate expansion from a beginning state. Within a sprint,
                        Message 11 of 14 , Apr 12 11:51 AM
                          I like your idea of using the word 'Expansion' instead of 'Creep',
                          but even then, it seems to indicate expansion from a beginning
                          state. Within a sprint, there is indeed an agreed upon beginning
                          state, and if anything is added during an iteration, I agree, this
                          is scope creep for the sprint, and it should be strongly discouraged.

                          But when looking at an overall project, I think the thing to fix and
                          now allow to creep is the 'mission'. This is a clear statement of
                          the objective of the project. It can be used at any time to
                          determine if an individual feature falls inside of or outside
                          of 'scope'. However, many features will fall inside of the box of
                          good things to do to achieve the objective. The thing to do then is
                          to figure out when to stop doing things that fall within the
                          mission. This happens when the justification for the expenditure
                          runs out, or an important deadline occurs.

                          To me (still a fan of burn-down charts) the thing that a burn-down
                          chart says to management is: here is a picture of what it will take
                          to finish the list if things in the backlog. Now I know you can't
                          spend that kind of money and don't have that kind of time, but
                          realistically, this is the bottom line. So, project sponsor, you
                          have to draw the line and cut off some of the lower priority
                          features on the backlog. Or you have to cut the backlog into pieces
                          and give a section to an additional team - which, by the way, is
                          guaranteed to slow things down at first.

                          I was on a project recently which was fixed price, but the deadline
                          was far more important to anyone than the price. We tried mightily
                          to do everything by the deadline, because the customer had
                          absolutely no incentive to say – `okay, we only need some of the
                          features.' They wanted every last feature, by the deadline. When
                          the deadline came and went and things were not working, they had a
                          choice – take a partially complete system and finish it later, or
                          miss the deadline. They choose the first.

                          What was remarkable was that they simply would not discuss partial
                          delivery until their backs were up to the wall, and only then would
                          they admit that a goodly number of the 'in scope' features really
                          were not necessary to meet the deadline. We need a way to force
                          this decision waaaay before the deadline.

                          Mary Poppendieck

                          > "Creep" is probably the condensing part of the phrase that needs
                          to > be revised. Scope will, at times, expand, as will the time
                          > required to complete a story or task relative to its estimate.
                          > A better term is not coming to mind at the moment. "Expansion"
                          > is what is my head.
                          >
                          > Lowell
                          > ====================
                          > Lowell Lindstrom
                          > Business Coach
                          > Object Mentor, Inc | www.objectmentor.com | 1-800-338-6716
                          > lindstrom@o...
                          >
                          >
                        • gilmanj_2000
                          I agree that the kind of scope creep that might exist inside of the scope of a sprint isn t interesting. This ought to be nothing more than the team s
                          Message 12 of 14 , Apr 13 8:16 AM
                            I agree that the kind of "scope creep" that might exist inside of
                            the scope of a sprint isn't interesting. This ought to be nothing
                            more than the team's changing understanding of additional tasks
                            necessary to accomplish the sprint goals. For this reason I don't
                            think a burn-up chart is very usefull in the context of a single
                            sprint.

                            On the other hand, when you must provide a projected release date
                            far out into the future based on incomplete or volitle scope
                            definition, it seems very valuable to me to highlight where the
                            original goal has changed because of changing client requirements,
                            changing management priorities, etc. Using a slightly pejoritive
                            term like "scope creep" is not necessarily a bad thing here.

                            John Gilman

                            --- In scrumdevelopment@yahoogroups.com, Russ Rufer <russ@p...>
                            wrote:
                            >
                            > Mike,
                            >
                            > The way scope is tracked on the Build Up Chart allows the chart to
                            be
                            > extended over time (say as a poster on a wall) without redrawing
                            the chart.
                            >
                            > Some history of scope revision can also be useful to explain
                            changes in
                            > projected target date. For example, if Feature X is removed from
                            your
                            > backlog because the large customer requesting it decided on
                            another
                            > vendor, that history would expose why the team was suddenly ahead
                            of
                            > their schedule for earlier estimates.
                            >
                            > If you want to hide (the complexity of) issues like that, and are
                            > redrawing your chart every time you want to update it, then a
                            single bar
                            > indicating scope at a point in time would suffice.
                            >
                            > Key, though, is separating scope revision from velocity. No one
                            has
                            > addressed my difficulties with Burn Down Charts yet (as expressed
                            in
                            > archive Messages 1149 and 1154) which led us to look at
                            alternatives.
                            >
                            > Consider a project that had a series of tasks removed from the
                            backlog,
                            > as in the above example. Without knowing additional details, the
                            most
                            > reasonable interpretation of a Burn Down Chart would be that the
                            team
                            > velocity had accelerated, and new target date predictions would be
                            based
                            > on that assumption. These new predictions would be flawed unless
                            tasks
                            > continued to be removed at a blistering pace, since actual
                            velocity
                            > probably didn't change. Build Up Charts expose the true velocity
                            > without regard to scope revision.
                            >
                            > - Russ
                            > Silicon Valley Patterns Group
                            >
                            >
                            > Mike Cohn wrote:
                            > > Great points, Mary. But one of your comments raises a question:
                            if the
                            > > length of the list is irrelevant (as you say in the next to last
                            > > paragraph, and which I agree with) then doesn't that mean a
                            build up
                            > > chart is irrelevant? Yes it shows a line going up instead of
                            down but
                            > > the introduction of additional lines showing the scope at
                            points in time
                            > > must now also be irrelevant, I'd think.
                            > >
                            > >
                            > >
                            > > -Mike
                          • robertallenhenley
                            ... One approach would be to reduce all of the preceeding data points by the amount of work removed from the Sprint backlog. The burn-down chart would then
                            Message 13 of 14 , Apr 16 8:41 AM
                              --- In scrumdevelopment@yahoogroups.com, Russ Rufer <russ@p...> wrote:
                              > Key, though, is separating scope revision from velocity.
                              > No one has addressed my difficulties with Burn Down Charts yet
                              > (as expressed in archive Messages 1149 and 1154) which led us to
                              > look at alternatives.

                              One approach would be to reduce all of the preceeding data points
                              by the amount of work removed from the Sprint backlog. The burn-down
                              chart would then look as if this work had never been taken on. That
                              would remove the "Sprint Signature" value of the burn-down chart
                              (showing which teams overcommit then reduce scope), but it would show
                              true velocity.

                              I do like "build-up" charts in that they appear to reflect both. But
                              they do not reflect changes in work estimates as distinct from
                              changes in scope. If I suddenly find that Feature X was trivial, the
                              change in the level bar is the same as if I had removed Feature X
                              from the Sprint Backlog. So we are left with a need for chart
                              annotation, or some other form of clarifying communication.

                              I think that these charts would be most useful within a Sprint to
                              reflect the team's understanding of work required to complete
                              features. They can also be used over multiple Sprints to reflect
                              Project Backlog, but these two uses should not be confused. Change
                              in the level bar in the later (multi-Sprint) case probably reflects
                              changes in scope for the release. Changes in the former (intra-
                              Sprint) case probably represent reevaluations of work required to be
                              done. (But without the annotations, we won't know.)

                              All the best,
                              Robert Henley
                              Software Architect and Engineer
                              Java/J2EE, XML, and Web Applications
                            • Bob Schatz
                              As a brand new just getting started SCRUM convert, I feel good to provide some input to the group on a new term to describe what we recognize as traditional
                              Message 14 of 14 , May 22, 2003
                                As a brand new just getting started SCRUM convert, I feel good to
                                provide some input to the group on a new term to describe what we
                                recognize as traditional Scope Creep. We have adopted the
                                term "Progressive Elaboration" as the politically correct term that
                                has smoothed the feathers of our Product Managers.

                                Bob Schatz
                                VP, Development
                                Primavera Systems, Inc


                                --- In scrumdevelopment@yahoogroups.com, "Mary Poppendieck"
                                <mary@p...> wrote:
                                > During the discussion of burn-up charts, now renamed build-up
                                charts, I have
                                > encountered several people talking about 'scope creep'.
                                >
                                >
                                >
                                > Personally, I do not believe in scope creep, and when viewed from
                                they eyes
                                > of a customer, 'scope creep' can come across as a condescending
                                term. I
                                > find it difficult to use the word 'scope creep' in front of a
                                customer in a
                                > way which does not sound pejorative.
                                >
                                >
                                >
                                > Customers have needs that they understand with more or less
                                clarity. They
                                > have a budget and a timeframe in which they wish to get those needs
                                > satisfied. In the process of satisfying those needs, the details
                                become
                                > clarified and things change. Thus the original understanding of
                                what was
                                > to be done changes. This is a normal, natural pattern in software
                                > development, but when it is labeled 'scope creep' it is thought of
                                as 'bad'.
                                >
                                >
                                >
                                >
                                > Software development is a series of try-it-test-it-fix it cycles
                                that span
                                > as much of the system as possible. These cycles improve
                                understanding of
                                > what it takes to achieve the business mission or objective. As
                                > understanding improves, it is useful to add ideas to the list of
                                things to
                                > be done. There is nothing wrong with a long backlog list - it
                                gathers
                                > together everyone's good ideas.
                                >
                                >
                                >
                                > The game to be played is to have a clear understanding that not
                                everything
                                > on the backlog is expected to be completed, and where the line is
                                drawn
                                > depends on when we run out of time and other resources. The
                                term 'scope
                                > creep' focuses people on the length of the list, which is
                                irrelevant,
                                > instead of the necessity of drawing the line part way down the
                                list, no
                                > matter how long it is. It is a waste of time to worry about
                                shortening the
                                > list, what we need to worry about is how to stop working when the
                                > justification and or time for the work is used up. Any method
                                which helps
                                > people to draw this line is useful. But it is not useful to focus
                                on the
                                > movement of items above and below the line as learning increases.
                                >
                                >
                                >
                                > Perhaps we might worry about 'mission creep', but it would seem to
                                me that
                                > with Scrum there is no such thing as scope creep, because there is
                                no
                                > attempt to fix scope to begin with, so there is nothing for scope
                                to creep
                                > away from.
                                >
                                >
                                >
                                > Mary Poppendieck
                                >
                                > www.poppendieck.com <http://www.poppendieck.com/>
                                >
                                > Author of
                                >
                                > Lean
                                <http://www.amazon.com/exec/obidos/ASIN/0321150783/poppendieckco-20>
                                > Software Development: An Agile Toolkit
                              Your message has been successfully submitted and would be delivered to recipients shortly.