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

RE: [scrumdevelopment] Re: Break down product backlog problem

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.