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

RE: [scrumdevelopment] Break down product backlog problem

Expand Messages
  • leo.ren@nsn.com
    thanks Srinivas. I believe our feature can be broken down. but that PM doesn t want to break it down. that s the problem. he thinks it s a waste of effort to
    Message 1 of 14 , Jan 3, 2008
    • 0 Attachment
      thanks Srinivas. I believe our feature can be broken down. but that PM doesn't want to break it down.
      that's the problem. he thinks it's a waste of effort to break it down and no value. I think he is used
      to waterfall(he is new PM from another company), although I try to convince him from risk and quick feedback aspects. but I failed. 
       

      Best Regards
      Leo Ren 



      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext srinivas chillara
      Sent: 2008年1月3日 19:04
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Break down product backlog problem

      Hello Leo,
       
      This sort of thinking that, things can't be broken, is mostly muddled thinking.
       
      If you are at a liberty to tell me/us what this feature is then mostly I can break it down for you.
      (contact me offline if you want to:  ceezone@yahoo. co.in  )
       
      One argument you can use is:
      If you think about developeing any fucntionality (either fresh or an enhancement) , as one codes, progress is made in steps. Some are insignificant, some others more significant and a few, very significant.
      At every significant step it is advisable to check in the code that "works". There are bound to be atleast a couple of significant (or very significant) steps in a given week, let alone a whole sprint. One can also think about these as fucntional milestones.  This milestones can be descibed as break points, and be used to breaking up the stories.
       
       
       
      Example:  Booking a plane ticket online.  (from a given list of available flights)
      Broken into
       
      First Sprint
      1)  Single person booking on single leg. (Standard rate, no discount or special fare), on a given date
       
      Second Sprint:
      2)Two or more passengers (family) booked at the same time, single leg.
      3) With special fares included
       
      Third Sprint
      4) Multiple leg, multiple passengers (no break journey)
       
      Fourth sprint
      .... Break journey allowed..... etc ....
       
       
       
      so on.....
       
       
       
      I think this comunity has to develop detailed real world examples.
       
      cheerio
      Cheenie
       
       
       
       
       
       
       


       
      ----- Original Message ----
      From: "leo.ren@nsn. com" <leo.ren@nsn. com>
      To: scrumdevelopment@ yahoogroups. com
      Sent: Thursday, 3 January, 2008 2:13:12 PM
      Subject: [scrumdevelopment] Break down product backlog problem

      Hi

          I encounter a problem when I convince one project manager when we break down product backlog.
      There is a feature, which can not be finished in one sprint, I suggest to break it down and finish
      Them within two sprints. But the PM doesn't agree with me, he thinks it's no value to do so. And
      He think we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.
      We should keep the duration of one sprint to be same.  But I can not convince him. Can anybody
      Help me? Or I'm wrong? Thanks.

      Best Regards
      Leo Ren 




      Now you can chat without downloading messenger. Click here to know how.

    • leo.ren@nsn.com
      Hi Tom you are right. this PM is not a scrum master. even more, he doesn t know agile. I know this is the problem of our organization, but that s fact. I have
      Message 2 of 14 , Jan 3, 2008
      • 0 Attachment
        Hi Tom
         
            you are right. this PM is not a scrum master. even more, he doesn't know agile.
        I know this is the problem of our organization, but that's fact. I have to face. acctually,
        he uses waterfall thinking because he is familiar with that .I will try to find another
        way to solve this problem. thanks.
         

        Best Regards
        Leo Ren 



        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext Tom Mellor
        Sent: 2008年1月3日 23:33
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: Break down product backlog problem

        Leo - you have encountered an issue that isn't unheard of, for sure.  First, you refer to the other person as the "project manager."  Is this person actually the ScrumMaster (and has he or she been trained as a Certified ScrumMaster? )  This is important, because if so, then he/she would understand the rationale for keeping Sprints a constant duration and receptive to your suggestion of breaking the feature down. 

        Not all work is suited for completing it within a Sprint - it would be great if it fit so nicely, but there can be technical work that spans two Sprints.  Ideally, the goal is to try to develop features and other technical requirements to a state of agreed done within an iteration.  If some work cannot be accomplished in that timeframe,  then the team needs to figure out how to best break it up (decompose it.)  The "PM" may not think it has value, but in the self-organized, self-directed team environment of Scrum, his opinion is simply one of several and the decision is not solely his/hers.

        Tom

        In scrumdevelopment@ yahoogroups. com, <leo.ren@...> wrote:
        I encounter a problem when I convince one project manager when we break down product backlog.  There is a feature, which can not be finished in one sprint, I suggest  to break it down and finish them within two sprints. But the PM doesn't agree with me, he thinks  it's no value to do so.   And he thinks we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.  We should keep the duration of one sprint to be same.  But I can not  convince him. Can anybody help me? Or I'm wrong?

      • Roy Morien
        Well, it looks like you ve got a typical obstinate, waterfall oriented PM, and he is not interested in agile development, and Scrum. Maybe you should just
        Message 3 of 14 , Jan 3, 2008
        • 0 Attachment
          Well, it looks like you've got a typical obstinate, "waterfall" oriented PM, and he is not interested in agile development, and Scrum. Maybe you should just feel a bit sorry for him, being so insulated from better ideas and so convinced that he is right.
           
          I have always said that the rules of Scrum, or any other method, are not so rigid that we must agonise about breaking those rules, but the fact is, when you start doing things that are totally contrary to the method that you are following, then you just cannot be said to be following that method, and you are just moving back to the old-fashioned, tried and failed methods of the past. The regular beat of iterations is a major characteristic of Scrum, and indeed mostother agile approaches, and to disturb that so much is making a nonsense of the claim that your following Scrum.
           
          Regards,
          Roy Morien





          To: scrumdevelopment@yahoogroups.com
          From: leo.ren@...
          Date: Fri, 4 Jan 2008 09:47:24 +0800
          Subject: RE: [scrumdevelopment] Break down product backlog problem

          thanks Srinivas. I believe our feature can be broken down. but that PM doesn't want to break it down.
          that's the problem. he thinks it's a waste of effort to break it down and no value. I think he is used
          to waterfall(he is new PM from another company), although I try to convince him from risk and quick feedback aspects. but I failed. 
           

          Best Regards
          Leo Ren 


          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of ext srinivas chillara
          Sent: 2008年1月3日 19:04
          To: scrumdevelopment@ yahoogroups. com
          Subject: Re: [scrumdevelopment] Break down product backlog problem

          Hello Leo,
           
          This sort of thinking that, things can't be broken, is mostly muddled thinking.
           
          If you are at a liberty to tell me/us what this feature is then mostly I can break it down for you.
          (contact me offline if you want to:  ceezone@yahoo. co.in  )
           
          One argument you can use is:
          If you think about developeing any fucntionality (either fresh or an enhancement) , as one codes, progress is made in steps. Some are insignificant, some others more significant and a few, very significant.
          At every significant step it is advisable to check in the code that "works". There are bound to be atleast a couple of significant (or very significant) steps in a given week, let alone a whole sprint. One can also think about these as fucntional milestones.  This milestones can be descibed as break points, and be used to breaking up the stories.
           
           
           
          Example:  Booking a plane ticket online.  (from a given list of available flights)
          Broken into
           
          First Sprint
          1)  Single person booking on single leg. (Standard rate, no discount or special fare), on a given date
           
          Second Sprint:
          2)Two or more passengers (family) booked at the same time, single leg.
          3) With special fares included
           
          Third Sprint
          4) Multiple leg, multiple passengers (no break journey)
           
          Fourth sprint
          .... Break journey allowed..... etc ....
           
           
           
          so on.....
           
           
           
          I think this comunity has to develop detailed real world examples.
           
          cheerio
          Cheenie
           
           
           
           
           
           
           


           
          ----- Original Message ----
          From: "leo.ren@nsn. com" <leo.ren@nsn. com>
          To: scrumdevelopment@ yahoogroups. com
          Sent: Thursday, 3 January, 2008 2:13:12 PM
          Subject: [scrumdevelopment] Break down product backlog problem

          Hi
              I encounter a problem when I convince one project manager when we break down product backlog.
          There is a feature, which can not be finished in one sprint, I suggest to break it down and finish
          Them within two sprints. But the PM doesn't agree with me, he thinks it's no value to do so. And
          He think we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.
          We should keep the duration of one sprint to be same.  But I can not convince him. Can anybody
          Help me? Or I'm wrong? Thanks.
          Best Regards
          Leo Ren 




          Now you can chat without downloading messenger. Click here to know how.



          Check our comprehensive Salary Centre Overpaid or Underpaid?
        • leo.ren@nsn.com
          Hi George he thinks he can control this project and his team without my suggesion.so he thinks it s no value :-( Best Regards Leo Ren From:
          Message 4 of 14 , Jan 3, 2008
          • 0 Attachment
            Hi George
             
                he thinks he can control this project and his team without my suggesion.so he thinks it's no value :-( 
             

            Best Regards
            Leo Ren  
             

             From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext George Dinwiddie
            Sent: 2008年1月4日 5:29
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Break down product backlog problem

            leo.ren@nsn. com wrote:

            >
            Hi
            >
            > I encounter a problem when I convince one project manager
            when we
            > break down product backlog.
            > There is a feature, which
            can not be finished in one sprint, I suggest
            > to break it down and
            finish
            > Them within two sprints. But the PM doesn't agree with me, he
            thinks
            > it's no value to do so. And
            > He think we can re-schedule
            this special sprint to twice of one normal
            > sprint duration. I think
            it's not good.
            > We should keep the duration of one sprint to be same. But
            I can not
            > convince him. Can anybody
            > Help me? Or I'm wrong?
            Thanks.

            Leo,

            One of the big benefits of working in small increments and short
            iterations is the visibility that gives to the progress being made and
            the feedback on whether things are going in the right direction. Surely
            your PM wouldn't want the team to go away for the entire project and
            return a year later with something that might, or might not, meet the
            desired needs. Not only might the delivered project not meet the needs,
            it might not be delivered at that time at all. By working in short
            iterations we see the growth of the project and can verify both progress
            and appropriateness. By keeping the iteration length fixed, we develop
            a rhythm, making this even easier without any mathematical calculations.

            If the PM finds no value in risk management by short iterations, then
            perhaps another tack will help. Even if the PM finds no value in
            keeping the iterations constant, ask him if he'll go along because of
            the value the team gets from it. There is quite a bit of value in
            maintaining the same rhythm of development so that you can concentrate
            on producing software rather than on the changing schedule. It's also
            easier to keep the focus on demonstrable working software. Longer
            iterations allow more opportunities to wander into unproductive habits.

            What value does the PM think that larger User Stories and variable
            Sprints have?

            - George

            --
            ------------ --------- --------- --------- --------- --------- -
            * George Dinwiddie * http://blog. gdinwiddie. com
            Software Development http://www.idiacomp uting.com
            Consultant and Coach http://www.agilemar yland.org
            ------------ --------- --------- --------- --------- --------- -

          • leo.ren@nsn.com
            yes, you are right, Roy. Best Regards Leo Ren ________________________________ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com]
            Message 5 of 14 , Jan 3, 2008
            • 0 Attachment
              yes, you are right, Roy.
               

              Best Regards
              Leo Ren 

               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext Roy Morien
              Sent: 2008年1月4日 9:53
              To: scrumdevelopment@yahoogroups.com
              Subject: RE: [scrumdevelopment] Break down product backlog problem

              Well, it looks like you've got a typical obstinate, "waterfall" oriented PM, and he is not interested in agile development, and Scrum. Maybe you should just feel a bit sorry for him, being so insulated from better ideas and so convinced that he is right.
               
              I have always said that the rules of Scrum, or any other method, are not so rigid that we must agonise about breaking those rules, but the fact is, when you start doing things that are totally contrary to the method that you are following, then you just cannot be said to be following that method, and you are just moving back to the old-fashioned, tried and failed methods of the past. The regular beat of iterations is a major characteristic of Scrum, and indeed mostother agile approaches, and to disturb that so much is making a nonsense of the claim that your following Scrum.
               
              Regards,
              Roy Morien





              To: scrumdevelopment@ yahoogroups. com
              From: leo.ren@nsn. com
              Date: Fri, 4 Jan 2008 09:47:24 +0800
              Subject: RE: [scrumdevelopment] Break down product backlog problem

              thanks Srinivas. I believe our feature can be broken down. but that PM doesn't want to break it down.
              that's the problem. he thinks it's a waste of effort to break it down and no value. I think he is used
              to waterfall(he is new PM from another company), although I try to convince him from risk and quick feedback aspects. but I failed. 
               

              Best Regards
              Leo Ren 


              From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of ext srinivas chillara
              Sent: 2008年1月3日 19:04
              To: scrumdevelopment@ yahoogroups. com
              Subject: Re: [scrumdevelopment] Break down product backlog problem

              Hello Leo,
               
              This sort of thinking that, things can't be broken, is mostly muddled thinking.
               
              If you are at a liberty to tell me/us what this feature is then mostly I can break it down for you.
              (contact me offline if you want to:  ceezone@yahoo. co.in  )
               
              One argument you can use is:
              If you think about developeing any fucntionality (either fresh or an enhancement) , as one codes, progress is made in steps. Some are insignificant, some others more significant and a few, very significant.
              At every significant step it is advisable to check in the code that "works". There are bound to be atleast a couple of significant (or very significant) steps in a given week, let alone a whole sprint. One can also think about these as fucntional milestones.  This milestones can be descibed as break points, and be used to breaking up the stories.
               
               
               
              Example:  Booking a plane ticket online.  (from a given list of available flights)
              Broken into
               
              First Sprint
              1)  Single person booking on single leg. (Standard rate, no discount or special fare), on a given date
               
              Second Sprint:
              2)Two or more passengers (family) booked at the same time, single leg.
              3) With special fares included
               
              Third Sprint
              4) Multiple leg, multiple passengers (no break journey)
               
              Fourth sprint
              .... Break journey allowed..... etc ....
               
               
               
              so on.....
               
               
               
              I think this comunity has to develop detailed real world examples.
               
              cheerio
              Cheenie
               
               
               
               
               
               
               


               
              ----- Original Message ----
              From: "leo.ren@nsn. com" <leo.ren@nsn. com>
              To: scrumdevelopment@ yahoogroups. com
              Sent: Thursday, 3 January, 2008 2:13:12 PM
              Subject: [scrumdevelopment] Break down product backlog problem

              Hi
                  I encounter a problem when I convince one project manager when we break down product backlog.
              There is a feature, which can not be finished in one sprint, I suggest to break it down and finish
              Them within two sprints. But the PM doesn't agree with me, he thinks it's no value to do so. And
              He think we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.
              We should keep the duration of one sprint to be same.  But I can not convince him. Can anybody
              Help me? Or I'm wrong? Thanks.
              Best Regards
              Leo Ren 




              Now you can chat without downloading messenger. Click here to know how.



              Check our comprehensive Salary Centre Overpaid or Underpaid?

            • Tom Mellor
              Ah, yes, it seems he is ferally tied to the tyranny of the waterfall. It is an all-too-familiar scene with few painless options or remedies. Well, other
              Message 6 of 14 , Jan 3, 2008
              • 0 Attachment
                Ah, yes, it seems he is "ferally tied to the tyranny of the
                waterfall." It is an all-too-familiar scene with few painless
                options or remedies. Well, other than taking him off the project
                and putting a CSM on it, there are few choices. The real suffering
                party here, I bet, is the team. Talk about confusing for them!!

                In fairness to the PM, he should at least be encouraged and provided
                the opportunity to attend CSM training asap, or otherwise be honest
                with himself and you if he concludes he won't or doesn't want to
                accept Scrum. I know of several companies where managers left after
                Scrum was adopted because they simply had no desire to give up
                positional authority in a command and control environment and try to
                change to lead in a self-directed team environment. John Chambers,
                CEO of Cisco, said that 15 to 20% of his leadership team "left"
                after the company moved to that environment. It isn't for everyone.

                One thing for sure, no one person should be allowed to impact a
                project or team detrimentally to the point where their behavior
                places the project at risk.

                --- In scrumdevelopment@yahoogroups.com, <leo.ren@...> wrote:
                >
                > Hi Tom
                >
                > you are right. this PM is not a scrum master. even more, he
                doesn't know agile.
                > I know this is the problem of our organization, but that's fact. I
                have to face. acctually,
                > he uses waterfall thinking because he is familiar with that .I
                will try to find another
                > way to solve this problem. thanks.
                >
                >
                > Best Regards
                > Leo Ren
                >
                >
                >
                > ________________________________
                >
                > From: scrumdevelopment@yahoogroups.com
                [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext Tom Mellor
                > Sent: 2008ǯ1·î3Æü 23:33
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] Re: Break down product backlog problem
                >
                >
                >
                > Leo - you have encountered an issue that isn't unheard of, for
                sure. First, you refer to the other person as the "project
                manager." Is this person actually the ScrumMaster (and has he or
                she been trained as a Certified ScrumMaster?) This is important,
                because if so, then he/she would understand the rationale for
                keeping Sprints a constant duration and receptive to your suggestion
                of breaking the feature down.
                >
                > Not all work is suited for completing it within a Sprint - it
                would be great if it fit so nicely, but there can be technical work
                that spans two Sprints. Ideally, the goal is to try to develop
                features and other technical requirements to a state of agreed done
                within an iteration. If some work cannot be accomplished in that
                timeframe, then the team needs to figure out how to best break it
                up (decompose it.) The "PM" may not think it has value, but in the
                self-organized, self-directed team environment of Scrum, his opinion
                is simply one of several and the decision is not solely his/hers.
                >
                > Tom
                >
                > In scrumdevelopment@yahoogroups.com, <leo.ren@> wrote:
                > I encounter a problem when I convince one project manager when we
                break down product backlog. There is a feature, which can not be
                finished in one sprint, I suggest to break it down and finish them
                within two sprints. But the PM doesn't agree with me, he thinks
                it's no value to do so. And he thinks we can re-schedule this
                special sprint to twice of one normal sprint duration. I think it's
                not good. We should keep the duration of one sprint to be same.
                But I can not convince him. Can anybody help me? Or I'm wrong?
                >
              • Roy Morien
                Tom, is the Cisco story documented anywhere? To: scrumdevelopment@yahoogroups.comFrom: tom.mellor.c5t2@statefarm.comDate: Fri, 4 Jan 2008 02:14:12
                Message 7 of 14 , Jan 3, 2008
                • 0 Attachment
                  Tom, is the Cisco story documented anywhere?




                  To: scrumdevelopment@yahoogroups.com
                  From: tom.mellor.c5t2@...
                  Date: Fri, 4 Jan 2008 02:14:12 +0000
                  Subject: [scrumdevelopment] Re: Break down product backlog problem

                  Ah, yes, it seems he is "ferally tied to the tyranny of the
                  waterfall." It is an all-too-familiar scene with few painless
                  options or remedies. Well, other than taking him off the project
                  and putting a CSM on it, there are few choices. The real suffering
                  party here, I bet, is the team. Talk about confusing for them!!

                  In fairness to the PM, he should at least be encouraged and provided
                  the opportunity to attend CSM training asap, or otherwise be honest
                  with himself and you if he concludes he won't or doesn't want to
                  accept Scrum. I know of several companies where managers left after
                  Scrum was adopted because they simply had no desire to give up
                  positional authority in a command and control environment and try to
                  change to lead in a self-directed team environment. John Chambers,
                  CEO of Cisco, said that 15 to 20% of his leadership team "left"
                  after the company moved to that environment. It isn't for everyone.

                  One thing for sure, no one person should be allowed to impact a
                  project or team detrimentally to the point where their behavior
                  places the project at risk.

                  --- In scrumdevelopment@ yahoogroups. com, <leo.ren@... > wrote:
                  >
                  > Hi Tom
                  >
                  > you are right. this PM is not a scrum master. even more, he
                  doesn't know agile.
                  > I know this is the problem of our organization, but that's fact. I
                  have to face. acctually,
                  > he uses waterfall thinking because he is familiar with that .I
                  will try to find another
                  > way to solve this problem. thanks.
                  >
                  >
                  > Best Regards
                  > Leo Ren
                  >
                  >
                  >
                  > ____________ _________ _________ __
                  >
                  > From: scrumdevelopment@ yahoogroups. com
                  [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of ext Tom Mellor
                  > Sent: 2008ǯ1·î3Æü 23:33
                  > To: scrumdevelopment@ yahoogroups. com
                  > Subject: [scrumdevelopment] Re: Break down product backlog problem
                  >
                  >
                  >
                  > Leo - you have encountered an issue that isn't unheard of, for
                  sure. First, you refer to the other person as the "project
                  manager." Is this person actually the ScrumMaster (and has he or
                  she been trained as a Certified ScrumMaster? ) This is important,
                  because if so, then he/she would understand the rationale for
                  keeping Sprints a constant duration and receptive to your suggestion
                  of breaking the feature down.
                  >
                  > Not all work is suited for completing it within a Sprint - it
                  would be great if it fit so nicely, but there can be technical work
                  that spans two Sprints. Ideally, the goal is to try to develop
                  features and other technical requirements to a state of agreed done
                  within an iteration. If some work cannot be accomplished in that
                  timeframe, then the team needs to figure out how to best break it
                  up (decompose it.) The "PM" may not think it has value, but in the
                  self-organized, self-directed team environment of Scrum, his opinion
                  is simply one of several and the decision is not solely his/hers.
                  >
                  > Tom
                  >
                  > In scrumdevelopment@ yahoogroups. com, <leo.ren@> wrote:
                  > I encounter a problem when I convince one project manager when we
                  break down product backlog. There is a feature, which can not be
                  finished in one sprint, I suggest to break it down and finish them
                  within two sprints. But the PM doesn't agree with me, he thinks
                  it's no value to do so. And he thinks we can re-schedule this
                  special sprint to twice of one normal sprint duration. I think it's
                  not good. We should keep the duration of one sprint to be same.
                  But I can not convince him. Can anybody help me? Or I'm wrong?
                  >




                  Join Lavalife for free. What are you waiting for?
                • an.narasimhan
                  I do not think it is a waterfall practice. Even if one uses Waterfall, features have to be broken down for better estimation. Estimation a large chuck cannot
                  Message 8 of 14 , Jan 3, 2008
                  • 0 Attachment
                    I do not think it is a waterfall practice. Even if one uses Waterfall, features have to be broken down for better estimation. Estimation a large chuck cannot be more accurate than estimating smaller chunks. This principle appliles everywhere. Even testing would be much more effective when features are broken down.

                    If you can do a review of estimates and actuals for couple of cases, maybe the PM may get convinced that it is better to break down features for better estimation, testability etc.
                    Rgds-AN

                    leo.ren@... wrote:

                    thanks Srinivas. I believe our feature can be broken down. but that PM doesn't want to break it down.
                    that's the problem. he thinks it's a waste of effort to break it down and no value. I think he is used
                    to waterfall(he is new PM from another company), although I try to convince him from risk and quick feedback aspects. but I failed. 
                     

                    Best Regards
                    Leo Ren 



                    From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of ext srinivas chillara
                    Sent: 2008年1月3日 19:04
                    To: scrumdevelopment@ yahoogroups. com
                    Subject: Re: [scrumdevelopment] Break down product backlog problem

                    Hello Leo,
                     
                    This sort of thinking that, things can't be broken, is mostly muddled thinking.
                     
                    If you are at a liberty to tell me/us what this feature is then mostly I can break it down for you.
                    (contact me offline if you want to:  ceezone@yahoo. co.in  )
                     
                    One argument you can use is:
                    If you think about developeing any fucntionality (either fresh or an enhancement) , as one codes, progress is made in steps. Some are insignificant, some others more significant and a few, very significant.
                    At every significant step it is advisable to check in the code that "works". There are bound to be atleast a couple of significant (or very significant) steps in a given week, let alone a whole sprint. One can also think about these as fucntional milestones.  This milestones can be descibed as break points, and be used to breaking up the stories.
                     
                     
                     
                    Example:  Booking a plane ticket online.  (from a given list of available flights)
                    Broken into
                     
                    First Sprint
                    1)  Single person booking on single leg. (Standard rate, no discount or special fare), on a given date
                     
                    Second Sprint:
                    2)Two or more passengers (family) booked at the same time, single leg.
                    3) With special fares included
                     
                    Third Sprint
                    4) Multiple leg, multiple passengers (no break journey)
                     
                    Fourth sprint
                    .... Break journey allowed..... etc ....
                     
                     
                     
                    so on.....
                     
                     
                     
                    I think this comunity has to develop detailed real world examples.
                     
                    cheerio
                    Cheenie
                     
                     
                     
                     
                     
                     
                     


                     
                    ----- Original Message ----
                    From: "leo.ren@nsn. com" <leo.ren@nsn. com>
                    To: scrumdevelopment@ yahoogroups. com
                    Sent: Thursday, 3 January, 2008 2:13:12 PM
                    Subject: [scrumdevelopment] Break down product backlog problem

                    Hi

                        I encounter a problem when I convince one project manager when we break down product backlog.
                    There is a feature, which can not be finished in one sprint, I suggest to break it down and finish
                    Them within two sprints. But the PM doesn't agree with me, he thinks it's no value to do so. And
                    He think we can re-schedule this special sprint to twice of one normal sprint duration. I think it's not good.
                    We should keep the duration of one sprint to be same.  But I can not convince him. Can anybody
                    Help me? Or I'm wrong? Thanks.

                    Best Regards
                    Leo Ren 




                    Now you can chat without downloading messenger. Click here to know how.

                  • woynam
                    Estimation is a means to an end, not the goal of iterative development. The driving force behind iterations is *feedback*. Even if a feature is incomplete
                    Message 9 of 14 , Jan 4, 2008
                    • 0 Attachment
                      Estimation is a means to an end, not the goal of iterative development.

                      The driving force behind iterations is *feedback*. Even if a feature
                      is incomplete after 1 iteration, we can gain valuable feedback. If the
                      feature is off-track, it's better to discover it sooner, rather than
                      later.

                      Leo has the tough job of convincing the PM that there are aspects of
                      the feature that can be completed in 1 iteration, such that the PO can
                      assess the correctness of the approach taken. Is there something about
                      the feature that is unknown? The reality is that even when everyone is
                      convinced that the feature is well understood, something creeps up
                      that was unexpected. You just don't know what you don't know.

                      Mark

                      --- In scrumdevelopment@yahoogroups.com, "an.narasimhan"
                      <an.narasimhan@...> wrote:
                      >
                      > I do not think it is a waterfall practice. Even if one uses Waterfall,
                      > features have to be broken down for better estimation. Estimation a
                      > large chuck cannot be more accurate than estimating smaller chunks. This
                      > principle appliles everywhere. Even testing would be much more effective
                      > when features are broken down.
                      >
                      > If you can do a review of estimates and actuals for couple of cases,
                      > maybe the PM may get convinced that it is better to break down features
                      > for better estimation, testability etc.
                      > Rgds-AN
                      >
                      > leo.ren@... wrote:
                      >
                      > > thanks Srinivas.I believe our feature can be broken down. but that PM
                      > > doesn't want to break it down.
                      > > that's the problem. he thinks it's a waste of effort to break it down
                      > > and no value. I think he is used
                      > > to waterfall(he is new PM from another company), although I try to
                      > > convince him from risk and quick feedback aspects. but I failed.
                      > >
                      > > Best Regards
                      > > Leo Ren
                      > >
                      > >
                      > >
                      ------------------------------------------------------------------------
                      > > From: scrumdevelopment@yahoogroups.com
                      > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of ext srinivas
                      > > chillara
                      > > Sent: 2008ǯ1·î3Æü 19:04
                      > > To: scrumdevelopment@yahoogroups.com
                      > > Subject: Re: [scrumdevelopment] Break down product backlog problem
                      > >
                      > > Hello Leo,
                      > > This sort of thinking that, things can't be broken, is mostly muddled
                      > > thinking.
                      > > If you are at a liberty to tell me/us what this feature is then mostly
                      > > I can break it down for you.
                      > > (contact me offline if you want to: ceezone@...
                      > > <mailto:ceezone@...> )
                      > > One argument you can use is:
                      > > If you think about developeing any fucntionality (either fresh or an
                      > > enhancement), as one codes, progress is made in steps. Some are
                      > > insignificant, some othersmore significant and a few, very
                      significant.
                      > > At every significant step it is advisable to check in the code that
                      > > "works". There are bound to be atleast a couple of significant (or
                      > > very significant) stepsin a given week, let alone a whole sprint.One
                      > > can also think about these as fucntional milestones. This milestones
                      > > can be descibed as break points, and be used to breaking up the
                      stories.
                      > > Example: Booking a plane ticket online. (from a givenlist of available
                      > > flights)
                      > > Broken into
                      > > First Sprint
                      > > 1) Single person booking on single leg. (Standard rate, no discount or
                      > > special fare), on a given date
                      > > Second Sprint:
                      > > 2)Two or more passengers (family)booked at the same time, single leg.
                      > > 3) With special fares included
                      > > Third Sprint
                      > > 4) Multiple leg, multiple passengers (no break journey)
                      > > Fourth sprint
                      > > .... Break journey allowed.....etc ....
                      > > so on.....
                      > > I think this comunity has to develop detailed real world examples.
                      > > cheerio
                      > > Cheenie
                      > >
                      > >
                      > > ----- Original Message ----
                      > > From: "leo.ren@..." <leo.ren@...>
                      > > To: scrumdevelopment@yahoogroups.com
                      > > Sent: Thursday, 3 January, 2008 2:13:12 PM
                      > > Subject: [scrumdevelopment] Break down product backlog problem
                      > >
                      > > Hi
                      > >
                      > > I encounter a problem when I convince one project manager when we
                      > > break down product backlog.
                      > > There is a feature, which can not be finished in one sprint, I suggest
                      > > to break it down and finish
                      > > Them within two sprints. But the PM doesn't agree with me, he thinks
                      > > it's no value to do so. And
                      > > He think we can re-schedule this special sprint to twice of one normal
                      > > sprint duration. I think it's not good.
                      > > We should keep the duration of one sprint to be same. But I can not
                      > > convince him. Can anybody
                      > > Help me? Or I'm wrong? Thanks.
                      > >
                      > > Best Regards
                      > > Leo Ren
                      > >
                      > >
                      > >
                      > >
                      ------------------------------------------------------------------------
                      > > Now you can chat without downloading messenger. Click here
                      > >
                      <http://in.rd.yahoo.com/tagline_webmessenger_5/*http://in.messenger.yahoo.com/webmessengerpromo.php>
                      > > to know how.
                      > >
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.