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

Break down product backlog problem

Expand Messages
  • leo.ren@nsn.com
    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
    Message 1 of 14 , Jan 3, 2008
    • 0 Attachment
      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 

    • srinivas chillara
      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
      Message 2 of 14 , Jan 3, 2008
      • 0 Attachment
        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@...  )
         
        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@..." <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 to know how.
      • Tom Mellor
        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
        Message 3 of 14 , Jan 3, 2008
        • 0 Attachment

          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?

        • George Dinwiddie
          ... 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
          Message 4 of 14 , Jan 3, 2008
          • 0 Attachment
            leo.ren@... 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.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • Angela Martin
            Hi Leo, As others have pointed out keeping sprint length constant is extremely useful, but I suspect to help answer your question we need to dig a little
            Message 5 of 14 , Jan 3, 2008
            • 0 Attachment
              Hi Leo,

              As others have pointed out keeping sprint length constant is extremely useful, but I suspect to help answer your question we need to dig a little deeper into the why the PM is concerned.  So are you able to provide a little more detail about what is concerning the project manager?  Is the sprint being discussed one that is externally or internally released?  How long are your sprints, how far into the project/product are you (how many sprints/months etc), how big is the team? ....

              Cheers,
              Angela

              On 03/01/2008, leo.ren@... <leo.ren@... > 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.

              Best Regards
              Leo Ren 




              --
              Angela Martin
              Aha! Facilitator

              Martin IT Consulting
              p : +44 7717 653 971
              e : angela@...
              w : http://www.martinitconsulting.com
            • 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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.