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

Re: PO causing iteration instability

Expand Messages
  • simons.online
    Hi Amit. As already mentioned, this is not an uncommon problem. It s difficult to provide a tangible answer without knowing what is the extent of the changes
    Message 1 of 24 , Aug 4, 2010
    • 0 Attachment
      Hi Amit. As already mentioned, this is not an uncommon problem. It's difficult to provide a tangible answer without knowing what is the extent of the changes and the root causes. You say that it's causing the team frustration, so my guess is that the adjustments are beyond what the team considers reasonable.

      Did this come up in the retros? Have you confronted the PO on this topic? Can you let us know what is the stance of the PO?

      Simon



      --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@...> wrote:
      >
      > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
      >
      > How to address such situations? I would appreciate your views on this.
      >
      > Regards,
      > Amit Agnihotri
      >
    • JackM
      The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way
      Message 2 of 24 , Aug 4, 2010
      • 0 Attachment
        The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way of just accepting changes mid-stream just undermines the teams commitment. I am not a believer in always taking the hardline approach so if a change can be negotiated in, in place of something else of equal size, I am semi ok with that.

        Jack
        www.agilebuddy.com
        blog.agilebuddy.com

        --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@...> wrote:
        >
        > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
        >
        > How to address such situations? I would appreciate your views on this.
        >
        > Regards,
        > Amit Agnihotri
        >
      • Roy Morien
        The phrase ... you may have to undo weeks of work. is a reminder of the fundamental problem of failing to validate and verify systematically, and
        Message 3 of 24 , Aug 4, 2010
        • 0 Attachment
          The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I  think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
           
          I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
           
          Regards,
          Roy Morien
           

          To: scrumdevelopment@yahoogroups.com
          From: woyna@...
          Date: Wed, 4 Aug 2010 16:01:20 +0000
          Subject: [scrumdevelopment] Re: PO causing iteration instability

           

          Fail fast.

          Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.

          Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.

          It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?

          There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.

          Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.

          Mark

          --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@...> wrote:
          >
          > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
          >
          > How to address such situations? I would appreciate your views on this.
          >
          > Regards,
          > Amit Agnihotri
          >


        • Agnihotri Amit
          Thanks all for valuable inputs. Shorten sprint to one week seems the right solution. Regards, Amit Agnihotri ... From: Roy Morien To:
          Message 4 of 24 , Aug 4, 2010
          • 0 Attachment
            Thanks all for valuable inputs.
             
            Shorten sprint to one week seems the right solution.
             
            Regards,
            Amit Agnihotri
             
             
            ----- Original Message -----
            Sent: Thursday, August 05, 2010 9:08 AM
            Subject: RE: [scrumdevelopment] Re: PO causing iteration instability

             

            The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I  think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
             
            I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
             
            Regards,
            Roy Morien
             


            To: scrumdevelopment@ yahoogroups. com
            From: woyna@argonne. com
            Date: Wed, 4 Aug 2010 16:01:20 +0000
            Subject: [scrumdevelopment] Re: PO causing iteration instability

             

            Fail fast.

            Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.

            Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.

            It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability" . What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?

            There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.

            Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.

            Mark

            --- In scrumdevelopm ent@ yahoogroups. com, "Agnihotri Amit" <aagnihotri@. ..> wrote:
            >
            > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
            >
            > How to address such situations? I would appreciate your views on this.
            >
            > Regards,
            > Amit Agnihotri
            >


          • Michael James
            The interesting part will be discovering what may prevent your team from building a properly-tested product increment every week. --mj
            Message 5 of 24 , Aug 4, 2010
            • 0 Attachment
              The interesting part will be discovering what may prevent your team from building a properly-tested product increment every week.

              --mj

              On Aug 4, 2010, at 11:21 PM, Agnihotri Amit wrote:

              >
              > Thanks all for valuable inputs.
              >
              > Shorten sprint to one week seems the right solution.
              >
              > Regards,
              > Amit Agnihotri
              >
              >
              > ----- Original Message -----
              > From: Roy Morien
              > To: scrumdevelopment@yahoogroups.com
              > Sent: Thursday, August 05, 2010 9:08 AM
              > Subject: RE: [scrumdevelopment] Re: PO causing iteration instability
              >
              >
              > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
              >
              > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
              >
              > Regards,
              > Roy Morien
              >
              > To: scrumdevelopment@yahoogroups.com
              > From: woyna@...
              > Date: Wed, 4 Aug 2010 16:01:20 +0000
              > Subject: [scrumdevelopment] Re: PO causing iteration instability
              >
              >
              >
              > Fail fast.
              >
              > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
              >
              > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
              >
              > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
              >
              > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
              >
              > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
              >
              > Mark
              >
              > --- In scrumdevelopm ent@yahoogroups.com, "Agnihotri Amit" <aagnihotri@...> wrote:
              > >
              > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
              > >
              > > How to address such situations? I would appreciate your views on this.
              > >
              > > Regards,
              > > Amit Agnihotri
              > >
              >
              >
              >
              >
              >
            • woynam
              The key question to me is whether the PO is changing the requirements, or clarifying the requirements. The goal of the Sprint is to deliver the functionality
              Message 6 of 24 , Aug 5, 2010
              • 0 Attachment
                The key question to me is whether the PO is changing the requirements, or clarifying the requirements.

                The goal of the Sprint is to deliver the functionality that the PO desires. If the PO is helping to steer that by working hand-in-hand with the team, then this should be a good thing.

                It sounds like the team is frustrated with the fact that developing software is a messy business. They're uncomfortable with change. Gee, wouldn't it be wonderful if the PO could spell it all out upfront, and then *go away* for a few weeks? It just doesn't happen like that very often. Teams that want to operate like this tend to spend waaaay too much time planning upfront.

                Isn't it better to start the iteration with a note card's worth of information, and incrementally add to the knowledge by implementing changes based on rapid feedback from the PO?

                Mark

                --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...> wrote:
                >
                >
                > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                >
                >
                >
                > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
                >
                >
                >
                > Regards,
                >
                > Roy Morien
                >
                >
                >
                > To: scrumdevelopment@yahoogroups.com
                > From: woyna@...
                > Date: Wed, 4 Aug 2010 16:01:20 +0000
                > Subject: [scrumdevelopment] Re: PO causing iteration instability
                >
                >
                >
                >
                >
                >
                >
                > Fail fast.
                >
                > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
                >
                > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
                >
                > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
                >
                > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
                >
                > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
                >
                > Mark
                >
                > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                > >
                > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                > >
                > > How to address such situations? I would appreciate your views on this.
                > >
                > > Regards,
                > > Amit Agnihotri
                > >
                >
              • simons.online
                There are some other things that I wonder about too. Is the PO effective at writing clear and manageable user stories? Does the PO undergo a reasonable process
                Message 7 of 24 , Aug 5, 2010
                • 0 Attachment
                  There are some other things that I wonder about too. Is the PO effective at writing clear and manageable user stories? Does the PO undergo a reasonable process for user story development; are the mid iteration changes triggered due to lack of forethought. I don't believe in too much upfront planning, but there should be a reasonable degree of development on requirements to avoid changes of major impact. You might want to refer to Mike Cohn's book on user stories. Most people refer to the 3 part format for user stories, but very few leverage the process for the development of the stories.

                  Reducing sprint lengths to 1 week may solve some problems, but may cause some others. I'm open to correction on this, but my understanding is that the guideline for sprint lengths are from 1-6 weeks. If shorter sprints are the cure all, why not just lay the law for 1 or 2 week sprints then? Moreover, I wonder if the general opinion is that you can't have manageable month long sprints? Experience has shown me that 1 week sprints are great for maintenance streams and enhancements, but you need longer cycles in order to ship completed functionality of any significant scale and complexity.



                  --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                  >
                  >
                  > The key question to me is whether the PO is changing the requirements, or clarifying the requirements.
                  >
                  > The goal of the Sprint is to deliver the functionality that the PO desires. If the PO is helping to steer that by working hand-in-hand with the team, then this should be a good thing.
                  >
                  > It sounds like the team is frustrated with the fact that developing software is a messy business. They're uncomfortable with change. Gee, wouldn't it be wonderful if the PO could spell it all out upfront, and then *go away* for a few weeks? It just doesn't happen like that very often. Teams that want to operate like this tend to spend waaaay too much time planning upfront.
                  >
                  > Isn't it better to start the iteration with a note card's worth of information, and incrementally add to the knowledge by implementing changes based on rapid feedback from the PO?
                  >
                  > Mark
                  >
                  > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                  > >
                  > >
                  > > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                  > >
                  > >
                  > >
                  > > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
                  > >
                  > >
                  > >
                  > > Regards,
                  > >
                  > > Roy Morien
                  > >
                  > >
                  > >
                  > > To: scrumdevelopment@yahoogroups.com
                  > > From: woyna@
                  > > Date: Wed, 4 Aug 2010 16:01:20 +0000
                  > > Subject: [scrumdevelopment] Re: PO causing iteration instability
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > > Fail fast.
                  > >
                  > > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
                  > >
                  > > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
                  > >
                  > > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
                  > >
                  > > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
                  > >
                  > > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
                  > >
                  > > Mark
                  > >
                  > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                  > > >
                  > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                  > > >
                  > > > How to address such situations? I would appreciate your views on this.
                  > > >
                  > > > Regards,
                  > > > Amit Agnihotri
                  > > >
                  > >
                  >
                • Roy Morien
                  I recollect the recommended sprint length to be 1-4 weeks, but I may be wrong, and I have also seen discussion here about even shorter sprint lenghts, but
                  Message 8 of 24 , Aug 6, 2010
                  • 0 Attachment
                    I recollect the recommended sprint length to be 1-4 weeks, but I may be wrong, and I have also seen discussion here about even shorter sprint lenghts, but never longer sprint lengths.
                     
                    I don't think there should be, or can be, a law laid down about this. I would expect there to be a sprint length diverged on that suits the team and the project type. What this will be is a matter of fact in the particular situation, but I doubt if it would be 1 month or longer.
                     
                    I run a little scared away from the statements "in order to ship completed functionality of any significant scale and complexity."  Beware the taking on of functionality of too significant a scale and too great a complexity".
                     
                    Regards,
                    Roy Morien


                     

                    To: scrumdevelopment@yahoogroups.com
                    From: simons.online@...
                    Date: Thu, 5 Aug 2010 17:39:18 +0000
                    Subject: [scrumdevelopment] Re: PO causing iteration instability

                     
                    There are some other things that I wonder about too. Is the PO effective at writing clear and manageable user stories? Does the PO undergo a reasonable process for user story development; are the mid iteration changes triggered due to lack of forethought. I don't believe in too much upfront planning, but there should be a reasonable degree of development on requirements to avoid changes of major impact. You might want to refer to Mike Cohn's book on user stories. Most people refer to the 3 part format for user stories, but very few leverage the process for the development of the stories.

                    Reducing sprint lengths to 1 week may solve some problems, but may cause some others. I'm open to correction on this, but my understanding is that the guideline for sprint lengths are from 1-6 weeks. If shorter sprints are the cure all, why not just lay the law for 1 or 2 week sprints then? Moreover, I wonder if the general opinion is that you can't have manageable month long sprints? Experience has shown me that 1 week sprints are great for maintenance streams and enhancements, but you need longer cycles in order to ship completed functionality of any significant scale and complexity.

                    --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                    >
                    >
                    > The key question to me is whether the PO is changing the requirements, or clarifying the requirements.
                    >
                    > The goal of the Sprint is to deliver the functionality that the PO desires. If the PO is helping to steer that by working hand-in-hand with the team, then this should be a good thing.
                    >
                    > It sounds like the team is frustrated with the fact that developing software is a messy business. They're uncomfortable with change. Gee, wouldn't it be wonderful if the PO could spell it all out upfront, and then *go away* for a few weeks? It just doesn't happen like that very often. Teams that want to operate like this tend to spend waaaay too much time planning upfront.
                    >
                    > Isn't it better to start the iteration with a note card's worth of information, and incrementally add to the knowledge by implementing changes based on rapid feedback from the PO?
                    >
                    > Mark
                    >
                    > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                    > >
                    > >
                    > > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                    > >
                    > >
                    > >
                    > > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
                    > >
                    > >
                    > >
                    > > Regards,
                    > >
                    > > Roy Morien
                    > >
                    > >
                    > >
                    > > To: scrumdevelopment@yahoogroups.com
                    > > From: woyna@
                    > > Date: Wed, 4 Aug 2010 16:01:20 +0000
                    > > Subject: [scrumdevelopment] Re: PO causing iteration instability
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > Fail fast.
                    > >
                    > > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
                    > >
                    > > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
                    > >
                    > > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
                    > >
                    > > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
                    > >
                    > > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
                    > >
                    > > Mark
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                    > > >
                    > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                    > > >
                    > > > How to address such situations? I would appreciate your views on this.
                    > > >
                    > > > Regards,
                    > > > Amit Agnihotri
                    > > >
                    > >
                    >


                  • Michael James
                    While there are no Scrum laws in my state, there are definitions. The maximum length of a Scrum Sprint is 30 days, and nowadays it s hard to justify one
                    Message 9 of 24 , Aug 6, 2010
                    • 0 Attachment
                      While there are no Scrum laws in my state, there are definitions. The maximum length of a Scrum Sprint is 30 days, and nowadays it's hard to justify one longer than two weeks. I propose the word "limp" for a 5 week iteration and "crawl" for 6 weeks.
                      --mj

                      On Aug 6, 2010, at 12:41 AM, Roy Morien wrote:

                      > I recollect the recommended sprint length to be 1-4 weeks, but I may be wrong, and I have also seen discussion here about even shorter sprint lenghts, but never longer sprint lengths.
                      >
                      > I don't think there should be, or can be, a law laid down about this. I would expect there to be a sprint length diverged on that suits the team and the project type. What this will be is a matter of fact in the particular situation, but I doubt if it would be 1 month or longer.
                      >
                      > I run a little scared away from the statements "in order to ship completed functionality of any significant scale and complexity." Beware the taking on of functionality of too significant a scale and too great a complexity".
                      >
                      > Regards,
                      > Roy Morien
                      >
                      >
                      >
                      > To: scrumdevelopment@yahoogroups.com
                      > From: simons.online@...
                      > Date: Thu, 5 Aug 2010 17:39:18 +0000
                      > Subject: [scrumdevelopment] Re: PO causing iteration instability
                      >
                      >
                      > There are some other things that I wonder about too. Is the PO effective at writing clear and manageable user stories? Does the PO undergo a reasonable process for user story development; are the mid iteration changes triggered due to lack of forethought. I don't believe in too much upfront planning, but there should be a reasonable degree of development on requirements to avoid changes of major impact. You might want to refer to Mike Cohn's book on user stories. Most people refer to the 3 part format for user stories, but very few leverage the process for the development of the stories.
                      >
                      > Reducing sprint lengths to 1 week may solve some problems, but may cause some others. I'm open to correction on this, but my understanding is that the guideline for sprint lengths are from 1-6 weeks. If shorter sprints are the cure all, why not just lay the law for 1 or 2 week sprints then? Moreover, I wonder if the general opinion is that you can't have manageable month long sprints? Experience has shown me that 1 week sprints are great for maintenance streams and enhancements, but you need longer cycles in order to ship completed functionality of any significant scale and complexity.
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                      > >
                      > >
                      > > The key question to me is whether the PO is changing the requirements, or clarifying the requirements.
                      > >
                      > > The goal of the Sprint is to deliver the functionality that the PO desires. If the PO is helping to steer that by working hand-in-hand with the team, then this should be a good thing.
                      > >
                      > > It sounds like the team is frustrated with the fact that developing software is a messy business. They're uncomfortable with change. Gee, wouldn't it be wonderful if the PO could spell it all out upfront, and then *go away* for a few weeks? It just doesn't happen like that very often. Teams that want to operate like this tend to spend waaaay too much time planning upfront.
                      > >
                      > > Isn't it better to start the iteration with a note card's worth of information, and incrementally add to the knowledge by implementing changes based on rapid feedback from the PO?
                      > >
                      > > Mark
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                      > > >
                      > > >
                      > > > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                      > > >
                      > > >
                      > > >
                      > > > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
                      > > >
                      > > >
                      > > >
                      > > > Regards,
                      > > >
                      > > > Roy Morien
                      > > >
                      > > >
                      > > >
                      > > > To: scrumdevelopment@yahoogroups.com
                      > > > From: woyna@
                      > > > Date: Wed, 4 Aug 2010 16:01:20 +0000
                      > > > Subject: [scrumdevelopment] Re: PO causing iteration instability
                      > > >
                      > > >
                      > > >
                      > > >
                      > > >
                      > > >
                      > > >
                      > > > Fail fast.
                      > > >
                      > > > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
                      > > >
                      > > > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
                      > > >
                      > > > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
                      > > >
                      > > > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
                      > > >
                      > > > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
                      > > >
                      > > > Mark
                      > > >
                      > > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                      > > > >
                      > > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                      > > > >
                      > > > > How to address such situations? I would appreciate your views on this.
                      > > > >
                      > > > > Regards,
                      > > > > Amit Agnihotri
                      > > > >
                      > > >
                      > >
                      >
                      >
                      >
                      >
                    • Roy Morien
                      Perhaps we could also adopt the terminology joke for anything longer than 6 weeks.
                      Message 10 of 24 , Aug 6, 2010
                      • 0 Attachment
                        Perhaps we could also adopt the terminology 'joke' for anything longer than 6 weeks.

                         
                        > To: scrumdevelopment@yahoogroups.com
                        > From: michael@...
                        > Date: Fri, 6 Aug 2010 01:22:00 -0700
                        > Subject: Re: [scrumdevelopment] Re: PO causing iteration instability
                        >
                        > While there are no Scrum laws in my state, there are definitions. The maximum length of a Scrum Sprint is 30 days, and nowadays it's hard to justify one longer than two weeks. I propose the word "limp" for a 5 week iteration and "crawl" for 6 weeks.
                        > --mj
                        >
                        > On Aug 6, 2010, at 12:41 AM, Roy Morien wrote:
                        >
                        > > I recollect the recommended sprint length to be 1-4 weeks, but I may be wrong, and I have also seen discussion here about even shorter sprint lenghts, but never longer sprint lengths.
                        > >
                        > > I don't think there should be, or can be, a law laid down about this. I would expect there to be a sprint length diverged on that suits the team and the project type. What this will be is a matter of fact in the particular situation, but I doubt if it would be 1 month or longer.
                        > >
                        > > I run a little scared away from the statements "in order to ship completed functionality of any significant scale and complexity." Beware the taking on of functionality of too significant a scale and too great a complexity".
                        > >
                        > > Regards,
                        > > Roy Morien
                        > >
                        > >
                        > >
                        > > To: scrumdevelopment@yahoogroups.com
                        > > From: simons.online@...
                        > > Date: Thu, 5 Aug 2010 17:39:18 +0000
                        > > Subject: [scrumdevelopment] Re: PO causing iteration instability
                        > >
                        > >
                        > > There are some other things that I wonder about too. Is the PO effective at writing clear and manageable user stories? Does the PO undergo a reasonable process for user story development; are the mid iteration changes triggered due to lack of forethought. I don't believe in too much upfront planning, but there should be a reasonable degree of development on requirements to avoid changes of major impact. You might want to refer to Mike Cohn's book on user stories. Most people refer to the 3 part format for user stories, but very few leverage the process for the development of the stories.
                        > >
                        > > Reducing sprint lengths to 1 week may solve some problems, but may cause some others. I'm open to correction on this, but my understanding is that the guideline for sprint lengths are from 1-6 weeks. If shorter sprints are the cure all, why not just lay the law for 1 or 2 week sprints then? Moreover, I wonder if the general opinion is that you can't have manageable month long sprints? Experience has shown me that 1 week sprints are great for maintenance streams and enhancements, but you need longer cycles in order to ship completed functionality of any significant scale and complexity.
                        > >
                        > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                        > > >
                        > > >
                        > > > The key question to me is whether the PO is changing the requirements, or clarifying the requirements.
                        > > >
                        > > > The goal of the Sprint is to deliver the functionality that the PO desires. If the PO is helping to steer that by working hand-in-hand with the team, then this should be a good thing.
                        > > >
                        > > > It sounds like the team is frustrated with the fact that developing software is a messy business. They're uncomfortable with change. Gee, wouldn't it be wonderful if the PO could spell it all out upfront, and then *go away* for a few weeks? It just doesn't happen like that very often. Teams that want to operate like this tend to spend waaaay too much time planning upfront.
                        > > >
                        > > > Isn't it better to start the iteration with a note card's worth of information, and incrementally add to the knowledge by implementing changes based on rapid feedback from the PO?
                        > > >
                        > > > Mark
                        > > >
                        > > > --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                        > > > >
                        > > > >
                        > > > > The phrase " ... you may have to undo weeks of work." is a reminder of the fundamental problem of failing to validate and verify systematically, and frequently. Frankly, I think this is the primary benefit arising from an iterative development approach, with short iterations. Clearly 'verifying and validating' once a month is not frequent enough. So, it may be possible to solve your problem, Amit, by taking that good piece of advice ... cut your iterations down to 1 or 2 weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                        > > > >
                        > > > >
                        > > > >
                        > > > > I can totally understand the PO wanting to make changes in the middle of the sprint. A month is too long to wait, and too much can be done tat is no longer necessary.
                        > > > >
                        > > > >
                        > > > >
                        > > > > Regards,
                        > > > >
                        > > > > Roy Morien
                        > > > >
                        > > > >
                        > > > >
                        > > > > To: scrumdevelopment@yahoogroups.com
                        > > > > From: woyna@
                        > > > > Date: Wed, 4 Aug 2010 16:01:20 +0000
                        > > > > Subject: [scrumdevelopment] Re: PO causing iteration instability
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > > Fail fast.
                        > > > >
                        > > > > Would you rather get the feedback now, or in the future? If you wait until the end of the iteration, you may have to undo weeks of work.
                        > > > >
                        > > > > Whether the requirements are "changing", or simply being uncovered, your primary goal is to deliver a product that meets the PO's needs. The sooner you make the necessary changes the better.
                        > > > >
                        > > > > It sounds like you're doing too much upfront planning at the kickoff meeting, since you consider changes to the artifacts "instability". What's unstable is that your artifacts are "wrong" right at the beginning. How much pain would it cause if you didn't prepare as much upfront?
                        > > > >
                        > > > > There are probably hundreds of teams that would like to have your problem, involvement and commitment by the PO.
                        > > > >
                        > > > > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less time planning, and have fewer "unstable" artifacts.
                        > > > >
                        > > > > Mark
                        > > > >
                        > > > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                        > > > > >
                        > > > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                        > > > > >
                        > > > > > How to address such situations? I would appreciate your views on this.
                        > > > > >
                        > > > > > Regards,
                        > > > > > Amit Agnihotri
                        > > > > >
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        > >
                        >
                        >
                        >
                        > ------------------------------------
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                        >
                        > <*> To visit your group on the web, go to:
                        > http://groups.yahoo.com/group/scrumdevelopment/
                        >
                        > <*> Your email settings:
                        > Individual Email | Traditional
                        >
                        > <*> To change settings online go to:
                        > http://groups.yahoo.com/group/scrumdevelopment/join
                        > (Yahoo! ID required)
                        >
                        > <*> To change settings via email:
                        > scrumdevelopment-digest@yahoogroups.com
                        > scrumdevelopment-fullfeatured@yahoogroups.com
                        >
                        > <*> To unsubscribe from this group, send an email to:
                        > scrumdevelopment-unsubscribe@yahoogroups.com
                        >
                        > <*> Your use of Yahoo! Groups is subject to:
                        > http://docs.yahoo.com/info/terms/
                        >
                      • Jeff Anderson
                        Try implementing a kanban style policy of allowing stories to be changed removed added until they have actually been started, formalize the PO interaction so
                        Message 11 of 24 , Aug 8, 2010
                        • 0 Attachment
                          Try implementing a kanban style policy of allowing stories to be
                          changed\removed\added until they have actually been started,

                          formalize the PO interaction so it operates at its own cadence,
                          independant of sprint cycle.

                          Its not pure scrum, but it may be the right approach to your situation...


                          Jeff

                          On 8/6/10, Roy Morien <roymorien@...> wrote:
                          >
                          > I recollect the recommended sprint length to be 1-4 weeks, but I may be
                          > wrong, and I have also seen discussion here about even shorter sprint
                          > lenghts, but never longer sprint lengths.
                          >
                          >
                          >
                          > I don't think there should be, or can be, a law laid down about this. I
                          > would expect there to be a sprint length diverged on that suits the team and
                          > the project type. What this will be is a matter of fact in the particular
                          > situation, but I doubt if it would be 1 month or longer.
                          >
                          >
                          >
                          > I run a little scared away from the statements "in order to ship completed
                          > functionality of any significant scale and complexity." Beware the taking
                          > on of functionality of too significant a scale and too great a complexity".
                          >
                          >
                          >
                          > Regards,
                          >
                          > Roy Morien
                          >
                          >
                          >
                          >
                          >
                          > To: scrumdevelopment@yahoogroups.com
                          > From: simons.online@...
                          > Date: Thu, 5 Aug 2010 17:39:18 +0000
                          > Subject: [scrumdevelopment] Re: PO causing iteration instability
                          >
                          >
                          >
                          >
                          >
                          >
                          > There are some other things that I wonder about too. Is the PO effective at
                          > writing clear and manageable user stories? Does the PO undergo a reasonable
                          > process for user story development; are the mid iteration changes triggered
                          > due to lack of forethought. I don't believe in too much upfront planning,
                          > but there should be a reasonable degree of development on requirements to
                          > avoid changes of major impact. You might want to refer to Mike Cohn's book
                          > on user stories. Most people refer to the 3 part format for user stories,
                          > but very few leverage the process for the development of the stories.
                          >
                          > Reducing sprint lengths to 1 week may solve some problems, but may cause
                          > some others. I'm open to correction on this, but my understanding is that
                          > the guideline for sprint lengths are from 1-6 weeks. If shorter sprints are
                          > the cure all, why not just lay the law for 1 or 2 week sprints then?
                          > Moreover, I wonder if the general opinion is that you can't have manageable
                          > month long sprints? Experience has shown me that 1 week sprints are great
                          > for maintenance streams and enhancements, but you need longer cycles in
                          > order to ship completed functionality of any significant scale and
                          > complexity.
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                          >>
                          >>
                          >> The key question to me is whether the PO is changing the requirements, or
                          >> clarifying the requirements.
                          >>
                          >> The goal of the Sprint is to deliver the functionality that the PO
                          >> desires. If the PO is helping to steer that by working hand-in-hand with
                          >> the team, then this should be a good thing.
                          >>
                          >> It sounds like the team is frustrated with the fact that developing
                          >> software is a messy business. They're uncomfortable with change. Gee,
                          >> wouldn't it be wonderful if the PO could spell it all out upfront, and
                          >> then *go away* for a few weeks? It just doesn't happen like that very
                          >> often. Teams that want to operate like this tend to spend waaaay too much
                          >> time planning upfront.
                          >>
                          >> Isn't it better to start the iteration with a note card's worth of
                          >> information, and incrementally add to the knowledge by implementing
                          >> changes based on rapid feedback from the PO?
                          >>
                          >> Mark
                          >>
                          >> --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@> wrote:
                          >> >
                          >> >
                          >> > The phrase " ... you may have to undo weeks of work." is a reminder of
                          >> > the fundamental problem of failing to validate and verify
                          >> > systematically, and frequently. Frankly, I think this is the primary
                          >> > benefit arising from an iterative development approach, with short
                          >> > iterations. Clearly 'verifying and validating' once a month is not
                          >> > frequent enough. So, it may be possible to solve your problem, Amit, by
                          >> > taking that good piece of advice ... cut your iterations down to 1 or 2
                          >> > weeks. I would prefer 1 week, but 2 weeks may be the winnable battle.
                          >> >
                          >> >
                          >> >
                          >> > I can totally understand the PO wanting to make changes in the middle of
                          >> > the sprint. A month is too long to wait, and too much can be done tat is
                          >> > no longer necessary.
                          >> >
                          >> >
                          >> >
                          >> > Regards,
                          >> >
                          >> > Roy Morien
                          >> >
                          >> >
                          >> >
                          >> > To: scrumdevelopment@yahoogroups.com
                          >> > From: woyna@
                          >> > Date: Wed, 4 Aug 2010 16:01:20 +0000
                          >> > Subject: [scrumdevelopment] Re: PO causing iteration instability
                          >> >
                          >> >
                          >> >
                          >> >
                          >> >
                          >> >
                          >> >
                          >> > Fail fast.
                          >> >
                          >> > Would you rather get the feedback now, or in the future? If you wait
                          >> > until the end of the iteration, you may have to undo weeks of work.
                          >> >
                          >> > Whether the requirements are "changing", or simply being uncovered, your
                          >> > primary goal is to deliver a product that meets the PO's needs. The
                          >> > sooner you make the necessary changes the better.
                          >> >
                          >> > It sounds like you're doing too much upfront planning at the kickoff
                          >> > meeting, since you consider changes to the artifacts "instability".
                          >> > What's unstable is that your artifacts are "wrong" right at the
                          >> > beginning. How much pain would it cause if you didn't prepare as much
                          >> > upfront?
                          >> >
                          >> > There are probably hundreds of teams that would like to have your
                          >> > problem, involvement and commitment by the PO.
                          >> >
                          >> > Why don't you cut the iterations down to 1 or 2 weeks? You'll spend less
                          >> > time planning, and have fewer "unstable" artifacts.
                          >> >
                          >> > Mark
                          >> >
                          >> > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@>
                          >> > wrote:
                          >> > >
                          >> > > I am facing a problem in my project where we plan month-long
                          >> > > iterations. PO in my project is reviewing the work done on daily basis
                          >> > > and providing instant feedback that involves minor to major changes
                          >> > > and asking us to incorporate those changes within same iteration. This
                          >> > > is causing instability with the user stories, design, code, test cases
                          >> > > & planned iteration tasks & dates and causing frustration amongst team
                          >> > > members.
                          >> > >
                          >> > > How to address such situations? I would appreciate your views on this.
                          >> > >
                          >> > > Regards,
                          >> > > Amit Agnihotri
                          >> > >
                          >> >
                          >>
                          >
                          >
                          >
                          >
                          >

                          --
                          Sent from my mobile device

                          Jeff Anderson

                          http://agileconsulting.blogspot.com/
                        • Steve Ropa
                          I have to agree with Gary on both points. You *want* the product owner to be changing things as they are discovered. This is how we identify that the
                          Message 12 of 24 , Aug 10, 2010
                          • 0 Attachment
                            I have to agree with Gary on both points.  You *want* the product owner to be changing things as they are discovered.  This is how we identify that the software we are creating is actually what the organization really wants.  Reducing the iteration length (and therefore more than likely the size/scope of your stories) will help act as a feedback mechanism to make sure that the changes and their impacts are immediately visible.
                             
                            I am also wondering about your mention of design, code, test cases, etc.  At first blush, seeing these activities called out as things that can get unstable makes me feel that maybe we still have some formal steps that are being inserted into the iteration.  If we are doing Test/Code cycles, and allowing the design to emerge accordingly, the disruption in this cycle due to changes should be minimal in most cases.
                             
                            Steve

                            Sent: Wednesday, August 04, 2010 9:10 AM
                            Subject: Re: [scrumdevelopment] PO causing iteration instability

                             

                            Hello, Amit!

                            Quoting Agnihotri Amit <aagnihotri@...>:

                            >
                            I am facing a problem in my project where we plan month-long
                            >
                            iterations. PO in my project is reviewing the work done on daily
                            > basis
                            and providing instant feedback that involves minor to major
                            > changes and
                            asking us to incorporate those changes within same
                            > iteration. This is
                            causing instability with the user stories,
                            > design, code, test cases
                            & planned iteration tasks & dates and
                            > causing frustration
                            amongst team members.
                            >
                            > How to address such situations? I would
                            appreciate your views on this.

                            I would allow it to happen, but note the impact to velocity, so you
                            can plan future iterations appropriately. Encourage the team to
                            understand that having a rapid communication and feedback loop is a
                            good thing for Agile teams.

                            Be thankful that you have an engaged PO!

                            Oh, and I would look at reducing that iteration length to one or two
                            weeks max.

                            GB.

                            ----------------------------------------------------------
                            This message was sent using IMP, the Internet Messaging Program.

                          • SeanH
                            I like this approach as well. Something doesn t sit right with people suggesting there s no harm in empowering the PO to make carte blanche changes over the
                            Message 13 of 24 , Aug 11, 2010
                            • 0 Attachment
                              I like this approach as well. Something doesn't sit right with people suggesting there's no harm in empowering the PO to make carte blanche changes over the course of the sprint. It can have a suppressive effect on the team's creativity, and as reported by the OP can kill team morale.

                              Most likely, a month is too long for the business to wait for a product increment, so reducing the duration of the sprint would probably make the PO feel less compelled to butt into the team's business on a daily basis.

                              --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@...> wrote:
                              >
                              > The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way of just accepting changes mid-stream just undermines the teams commitment. I am not a believer in always taking the hardline approach so if a change can be negotiated in, in place of something else of equal size, I am semi ok with that.
                              >
                              > Jack
                              > www.agilebuddy.com
                              > blog.agilebuddy.com
                              >
                              > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                              > >
                              > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                              > >
                              > > How to address such situations? I would appreciate your views on this.
                              > >
                              > > Regards,
                              > > Amit Agnihotri
                              > >
                              >
                            • woynam
                              The original poster never provided examples of how the PO made carte blanche changes. Depending on how you look at it, the PO may have been providing more
                              Message 14 of 24 , Aug 11, 2010
                              • 0 Attachment
                                The original poster never provided examples of how the PO made "carte blanche" changes. Depending on how you look at it, the PO may have been providing more detail for the selected stories. I certainly didn't get the impression that the PO was changing what stories were being worked on, but rather, the details of the stories selected at the kickoff meeting.

                                It sounded to me as if the team did too much upfront design, and didn't like the fact that the PO's clarifications resulted in waste.

                                Something doesn't sit right with me when a team tells an involved PO to go away while they build the wrong thing. The fact that they can correct it in the next iteration doesn't change the fact that you're potentially building the wrong thing. The sooner you discover this, the better.

                                Mark

                                --- In scrumdevelopment@yahoogroups.com, "SeanH" <seanh242@...> wrote:
                                >
                                > I like this approach as well. Something doesn't sit right with people suggesting there's no harm in empowering the PO to make carte blanche changes over the course of the sprint. It can have a suppressive effect on the team's creativity, and as reported by the OP can kill team morale.
                                >
                                > Most likely, a month is too long for the business to wait for a product increment, so reducing the duration of the sprint would probably make the PO feel less compelled to butt into the team's business on a daily basis.
                                >
                                > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
                                > >
                                > > The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way of just accepting changes mid-stream just undermines the teams commitment. I am not a believer in always taking the hardline approach so if a change can be negotiated in, in place of something else of equal size, I am semi ok with that.
                                > >
                                > > Jack
                                > > www.agilebuddy.com
                                > > blog.agilebuddy.com
                                > >
                                > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                                > > >
                                > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                                > > >
                                > > > How to address such situations? I would appreciate your views on this.
                                > > >
                                > > > Regards,
                                > > > Amit Agnihotri
                                > > >
                                > >
                                >
                              • Roy Morien
                                Good point, Mark. You have highlighted one of the dangers of BDUF (Big Design Upfront) where the designers get so wedded to their up-front design that any
                                Message 15 of 24 , Aug 11, 2010
                                • 0 Attachment
                                  Good point, Mark. You have highlighted one of the dangers of BDUF (Big Design Upfront) where the designers get so wedded to their up-front design that any change is seen as an irritant, or proof that the client is an idiot and a meddler. The client, in their turn, start to see the developers as arrogant fools who can't be told.  Not a happy relationship, but unfortunately very common.
                                   
                                  Not that I am suggesting that this is the case in te situation described by the initial poster ... but ... maybe!
                                   
                                  Regards,
                                  Roy Morien
                                   

                                  To: scrumdevelopment@yahoogroups.com
                                  From: woyna@...
                                  Date: Wed, 11 Aug 2010 21:38:45 +0000
                                  Subject: [scrumdevelopment] Re: PO causing iteration instability

                                   

                                  The original poster never provided examples of how the PO made "carte blanche" changes. Depending on how you look at it, the PO may have been providing more detail for the selected stories. I certainly didn't get the impression that the PO was changing what stories were being worked on, but rather, the details of the stories selected at the kickoff meeting.

                                  It sounded to me as if the team did too much upfront design, and didn't like the fact that the PO's clarifications resulted in waste.

                                  Something doesn't sit right with me when a team tells an involved PO to go away while they build the wrong thing. The fact that they can correct it in the next iteration doesn't change the fact that you're potentially building the wrong thing. The sooner you discover this, the better.

                                  Mark

                                  --- In scrumdevelopment@yahoogroups.com, "SeanH" <seanh242@...> wrote:
                                  >
                                  > I like this approach as well. Something doesn't sit right with people suggesting there's no harm in empowering the PO to make carte blanche changes over the course of the sprint. It can have a suppressive effect on the team's creativity, and as reported by the OP can kill team morale.
                                  >
                                  > Most likely, a month is too long for the business to wait for a product increment, so reducing the duration of the sprint would probably make the PO feel less compelled to butt into the team's business on a daily basis.
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
                                  > >
                                  > > The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way of just accepting changes mid-stream just undermines the teams commitment. I am not a believer in always taking the hardline approach so if a change can be negotiated in, in place of something else of equal size, I am semi ok with that.
                                  > >
                                  > > Jack
                                  > > www.agilebuddy.com
                                  > > blog.agilebuddy.com
                                  > >
                                  > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                                  > > >
                                  > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                                  > > >
                                  > > > How to address such situations? I would appreciate your views on this.
                                  > > >
                                  > > > Regards,
                                  > > > Amit Agnihotri
                                  > > >
                                  > >
                                  >


                                • SeanH
                                  You can always have too much of a good thing, and a hyper-involved PO is no exception. There is no more evidence that the team is doing too much upfront
                                  Message 16 of 24 , Aug 12, 2010
                                  • 0 Attachment
                                    You can always have too much of a good thing, and a hyper-involved PO is no exception. There is no more evidence that the team is doing too much upfront design than there is that the PO is breaking the contract of work agreed upon at the beginning of the iteration. I would suggest there is more evidence to the latter, in fact, as Amit indicates "that involves minor to major changes and asking us to incorporate those changes within same iteration." The original poster also hints at "story instability."

                                    Something that doesn't sit right with me is the assumption that if the product owner doesn't like the way the work is turning out, the team must be doing something wrong. Operating under that assumption means you're allowing fear of failure to drive the team. Instead, failure should be embraced, and used as a tool for learning. Let the consequences of failure be realized, and deal with and learn from those consequences at the end of the iteration, rather than trying to hide something that may be a source of great dysfunction. Perhaps the stories are too vague, or too large. Perhaps the team needs to get more involved in helping the PO groom the backlog. None of these issues could possibly surface if the PO is interfering with the team's daily work. Let it fail. Then the causes can be discovered, no matter where they lie. If the business cannot abide waiting a month to inspect progress, then shorten the duration of the iteration.


                                    --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                    >
                                    >
                                    > The original poster never provided examples of how the PO made "carte blanche" changes. Depending on how you look at it, the PO may have been providing more detail for the selected stories. I certainly didn't get the impression that the PO was changing what stories were being worked on, but rather, the details of the stories selected at the kickoff meeting.
                                    >
                                    > It sounded to me as if the team did too much upfront design, and didn't like the fact that the PO's clarifications resulted in waste.
                                    >
                                    > Something doesn't sit right with me when a team tells an involved PO to go away while they build the wrong thing. The fact that they can correct it in the next iteration doesn't change the fact that you're potentially building the wrong thing. The sooner you discover this, the better.
                                    >
                                    > Mark
                                    >
                                    > --- In scrumdevelopment@yahoogroups.com, "SeanH" <seanh242@> wrote:
                                    > >
                                    > > I like this approach as well. Something doesn't sit right with people suggesting there's no harm in empowering the PO to make carte blanche changes over the course of the sprint. It can have a suppressive effect on the team's creativity, and as reported by the OP can kill team morale.
                                    > >
                                    > > Most likely, a month is too long for the business to wait for a product increment, so reducing the duration of the sprint would probably make the PO feel less compelled to butt into the team's business on a daily basis.
                                    > >
                                    > > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
                                    > > >
                                    > > > The best way to deal with this is to shorten the iteration. So go with one week or two week iterations and your PO can impact changes more often. The other way of just accepting changes mid-stream just undermines the teams commitment. I am not a believer in always taking the hardline approach so if a change can be negotiated in, in place of something else of equal size, I am semi ok with that.
                                    > > >
                                    > > > Jack
                                    > > > www.agilebuddy.com
                                    > > > blog.agilebuddy.com
                                    > > >
                                    > > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                                    > > > >
                                    > > > > I am facing a problem in my project where we plan month-long iterations. PO in my project is reviewing the work done on daily basis and providing instant feedback that involves minor to major changes and asking us to incorporate those changes within same iteration. This is causing instability with the user stories, design, code, test cases & planned iteration tasks & dates and causing frustration amongst team members.
                                    > > > >
                                    > > > > How to address such situations? I would appreciate your views on this.
                                    > > > >
                                    > > > > Regards,
                                    > > > > Amit Agnihotri
                                    > > > >
                                    > > >
                                    > >
                                    >
                                  • daswartz@prodigy
                                    Hello SeanH, ... I suppose that is true, but it s never been the case in my experience. ... Certainly, we don t know enough from the postings in this thread to
                                    Message 17 of 24 , Aug 12, 2010
                                    • 0 Attachment
                                      Hello SeanH,

                                      Thursday, August 12, 2010, 10:24:25 AM, you wrote:

                                      > You can always have too much of a good thing, and a hyper-involved
                                      > PO is no exception.

                                      I suppose that is true, but it's never been the case in my
                                      experience.

                                      > There is no more evidence that the team is
                                      > doing too much upfront design than there is that the PO is breaking
                                      > the contract of work agreed upon at the beginning of the iteration.
                                      > I would suggest there is more evidence to the latter, in fact, as
                                      > Amit indicates "that involves minor to major changes and asking us
                                      > to incorporate those changes within same iteration." The original
                                      > poster also hints at "story instability."

                                      Certainly, we don't know enough from the postings in this thread to
                                      diagnose the causes of "who is at fault". And that shouldn't be the
                                      goal, anyway. I do believe we can see that there is a problem,
                                      however, because Amit and the development team feel frustrated.

                                      > Something that doesn't sit right with me is the assumption that if
                                      > the product owner doesn't like the way the work is turning out, the
                                      > team must be doing something wrong. Operating under that assumption
                                      > means you're allowing fear of failure to drive the team. Instead,
                                      > failure should be embraced, and used as a tool for learning. Let
                                      > the consequences of failure be realized, and deal with and learn
                                      > from those consequences at the end of the iteration, rather than
                                      > trying to hide something that may be a source of great dysfunction.
                                      > Perhaps the stories are too vague, or too large. Perhaps the team
                                      > needs to get more involved in helping the PO groom the backlog.
                                      > None of these issues could possibly surface if the PO is interfering
                                      > with the team's daily work. Let it fail. Then the causes can be
                                      > discovered, no matter where they lie. If the business cannot abide
                                      > waiting a month to inspect progress, then shorten the duration of the iteration.

                                      Personally I love it when we can demonstrate progress on
                                      stories to the PO every day, especially when the stories are
                                      highly user interface oriented. This allows the PO to give feedback
                                      based on something much more concrete than a mockup or design, but
                                      before we've invested a large amount of developer time.

                                      However, I can imagine everyone's time could be used more
                                      efficiently if the "daily demo" and PO discussion is scheduled:
                                      Perhaps immediately after the daily meeting, or at some other time
                                      when the PO usually has time available. This could minimize
                                      disruptions to the developers' flow while still getting the best
                                      product the PO can devise.

                                      I hope the PO is as involved in the retrospectives as he is
                                      involved in the daily work. If this frustration about changing stories
                                      doesn't surface there, I hope Amit will bring it up. If velocity
                                      is impacted, as I assume it is, and there is some date the PO and team
                                      are trying to hit with the project, that should be pretty easily shown.
                                      My personal experience is that POs who have a difficult time making up
                                      their mind on features, often don't have a good grasp on how shifting
                                      feature requirements are impacting the project time-frame and/or budget.

                                      "Fixes" for the problem could include any of the things mentioned in
                                      this thread: shorter iterations, less up-front designing, more developer
                                      involvement in PBI grooming, smaller stories, adjusting scope of the
                                      project to allow for fewer, but better, features, etc. Only Amit and
                                      the team on-site have enough knowledge to know which fixes might make
                                      sense for them. The key is for the "Whole team", PO, developers,
                                      ScrumMaster, Project Manager, testers, etc., to have a common
                                      understanding of the current state, to all agree to try procedural
                                      changes, and to monitor the results and adjust again at the next
                                      iteration based on results.

                                      Doug Swartz

                                      > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
                                      >>
                                      >>
                                      >> The original poster never provided examples of how the PO made
                                      >> "carte blanche" changes. Depending on how you look at it, the PO
                                      >> may have been providing more detail for the selected stories. I
                                      >> certainly didn't get the impression that the PO was changing what
                                      >> stories were being worked on, but rather, the details of the
                                      >> stories selected at the kickoff meeting.
                                      >>
                                      >> It sounded to me as if the team did too much upfront design, and
                                      >> didn't like the fact that the PO's clarifications resulted in
                                      >> waste.
                                      >>
                                      >> Something doesn't sit right with me when a team tells an involved
                                      >> PO to go away while they build the wrong thing. The fact that they
                                      >> can correct it in the next iteration doesn't change the fact that
                                      >> you're potentially building the wrong thing. The sooner you
                                      >> discover this, the better.
                                      >>
                                      >> Mark
                                      >>
                                      >> --- In scrumdevelopment@yahoogroups.com, "SeanH" <seanh242@> wrote:
                                      >> >
                                      >> > I like this approach as well. Something doesn't sit right with
                                      >> people suggesting there's no harm in empowering the PO to make
                                      >> carte blanche changes over the course of the sprint. It can have a
                                      >> suppressive effect on the team's creativity, and as reported by the
                                      >> OP can kill team morale.
                                      >> >
                                      >> > Most likely, a month is too long for the business to wait for a
                                      >> product increment, so reducing the duration of the sprint would
                                      >> probably make the PO feel less compelled to butt into the team's
                                      >> business on a daily basis.
                                      >> >
                                      >> > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
                                      >> > >
                                      >> > > The best way to deal with this is to shorten the iteration. So
                                      >> go with one week or two week iterations and your PO can impact
                                      >> changes more often. The other way of just accepting changes
                                      >> mid-stream just undermines the teams commitment. I am not a
                                      >> believer in always taking the hardline approach so if a change can
                                      >> be negotiated in, in place of something else of equal size, I am
                                      >> semi ok with that.
                                      >> > >
                                      >> > > Jack
                                      >> > > www.agilebuddy.com
                                      >> > > blog.agilebuddy.com
                                      >> > >
                                      >> > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                                      >> > > >
                                      >> > > > I am facing a problem in my project where we plan month-long
                                      >> iterations. PO in my project is reviewing the work done on daily
                                      >> basis and providing instant feedback that involves minor to major
                                      >> changes and asking us to incorporate those changes within same
                                      >> iteration. This is causing instability with the user stories,
                                      >> design, code, test cases & planned iteration tasks & dates and
                                      >> causing frustration amongst team members.
                                      >> > > >
                                      >> > > > How to address such situations? I would appreciate your views
                                      >> on this.
                                      >> > > >
                                      >> > > > Regards,
                                      >> > > > Amit Agnihotri
                                    • woynam
                                      Excellent, Doug. I m currently serving as a PO for an internal, web-based application. The team deploys a build to our sandbox every night. Each day I get to
                                      Message 18 of 24 , Aug 12, 2010
                                      • 0 Attachment
                                        Excellent, Doug.

                                        I'm currently serving as a PO for an internal, web-based application. The team deploys a build to our sandbox every night. Each day I get to kick the tires, performing ad-hoc testing. There's nothing like getting working software every day to uncover potential issues. Most of the things we've uncovered so far were not considered during the initial planning for the iteration.

                                        Now, at times the team does get frustrated that things have "changed". Isn't this why we do agile? :-)

                                        In many cases it's the addition of new scenarios, and we add them (stories) to the backlog. However, if the new knowledge affects the current scenario/story, then we typically tackle it right now. I don't see much sense in ignoring the reality of the moment for the outdated view from the past.

                                        In particular, we use fairly low-fidelity mock ups during the feature discussions. Once we get the real software partially working, it's a lot easier to identify usability issues, and address them immediately.

                                        In a nutshell, it would be wonderful if everything could be nailed down during planning. Of course, I'd like to win the lottery, too, but it just ain't going to happen. As the customer proxy, I have to balance between order and chaos, knowing full well that changes will definitely affect the project "plan" in one way or another. But then again, that's why we continuously plan in agile projects.

                                        I guess where this is heading is toward continuous Scrum. The iteration boundaries are really only useful for measuring velocity, so we can get an idea of the overall length of the project. However, once the iteration starts, we're effectively running on one day sprints. When a team member is available, they grab the next ready story from the prioritized backlog. As long as the stories have enough detail to get started, and I'm available for Q&A, the story progresses until done, which is typically one to 3 days.

                                        Mark


                                        --- In scrumdevelopment@yahoogroups.com, "daswartz@..." <daswartz@...> wrote:
                                        >
                                        > Hello SeanH,
                                        >
                                        > Thursday, August 12, 2010, 10:24:25 AM, you wrote:
                                        >
                                        > > You can always have too much of a good thing, and a hyper-involved
                                        > > PO is no exception.
                                        >
                                        > I suppose that is true, but it's never been the case in my
                                        > experience.
                                        >
                                        > > There is no more evidence that the team is
                                        > > doing too much upfront design than there is that the PO is breaking
                                        > > the contract of work agreed upon at the beginning of the iteration.
                                        > > I would suggest there is more evidence to the latter, in fact, as
                                        > > Amit indicates "that involves minor to major changes and asking us
                                        > > to incorporate those changes within same iteration." The original
                                        > > poster also hints at "story instability."
                                        >
                                        > Certainly, we don't know enough from the postings in this thread to
                                        > diagnose the causes of "who is at fault". And that shouldn't be the
                                        > goal, anyway. I do believe we can see that there is a problem,
                                        > however, because Amit and the development team feel frustrated.
                                        >
                                        > > Something that doesn't sit right with me is the assumption that if
                                        > > the product owner doesn't like the way the work is turning out, the
                                        > > team must be doing something wrong. Operating under that assumption
                                        > > means you're allowing fear of failure to drive the team. Instead,
                                        > > failure should be embraced, and used as a tool for learning. Let
                                        > > the consequences of failure be realized, and deal with and learn
                                        > > from those consequences at the end of the iteration, rather than
                                        > > trying to hide something that may be a source of great dysfunction.
                                        > > Perhaps the stories are too vague, or too large. Perhaps the team
                                        > > needs to get more involved in helping the PO groom the backlog.
                                        > > None of these issues could possibly surface if the PO is interfering
                                        > > with the team's daily work. Let it fail. Then the causes can be
                                        > > discovered, no matter where they lie. If the business cannot abide
                                        > > waiting a month to inspect progress, then shorten the duration of the iteration.
                                        >
                                        > Personally I love it when we can demonstrate progress on
                                        > stories to the PO every day, especially when the stories are
                                        > highly user interface oriented. This allows the PO to give feedback
                                        > based on something much more concrete than a mockup or design, but
                                        > before we've invested a large amount of developer time.
                                        >
                                        > However, I can imagine everyone's time could be used more
                                        > efficiently if the "daily demo" and PO discussion is scheduled:
                                        > Perhaps immediately after the daily meeting, or at some other time
                                        > when the PO usually has time available. This could minimize
                                        > disruptions to the developers' flow while still getting the best
                                        > product the PO can devise.
                                        >
                                        > I hope the PO is as involved in the retrospectives as he is
                                        > involved in the daily work. If this frustration about changing stories
                                        > doesn't surface there, I hope Amit will bring it up. If velocity
                                        > is impacted, as I assume it is, and there is some date the PO and team
                                        > are trying to hit with the project, that should be pretty easily shown.
                                        > My personal experience is that POs who have a difficult time making up
                                        > their mind on features, often don't have a good grasp on how shifting
                                        > feature requirements are impacting the project time-frame and/or budget.
                                        >
                                        > "Fixes" for the problem could include any of the things mentioned in
                                        > this thread: shorter iterations, less up-front designing, more developer
                                        > involvement in PBI grooming, smaller stories, adjusting scope of the
                                        > project to allow for fewer, but better, features, etc. Only Amit and
                                        > the team on-site have enough knowledge to know which fixes might make
                                        > sense for them. The key is for the "Whole team", PO, developers,
                                        > ScrumMaster, Project Manager, testers, etc., to have a common
                                        > understanding of the current state, to all agree to try procedural
                                        > changes, and to monitor the results and adjust again at the next
                                        > iteration based on results.
                                        >
                                        > Doug Swartz
                                        >
                                        > > --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@> wrote:
                                        > >>
                                        > >>
                                        > >> The original poster never provided examples of how the PO made
                                        > >> "carte blanche" changes. Depending on how you look at it, the PO
                                        > >> may have been providing more detail for the selected stories. I
                                        > >> certainly didn't get the impression that the PO was changing what
                                        > >> stories were being worked on, but rather, the details of the
                                        > >> stories selected at the kickoff meeting.
                                        > >>
                                        > >> It sounded to me as if the team did too much upfront design, and
                                        > >> didn't like the fact that the PO's clarifications resulted in
                                        > >> waste.
                                        > >>
                                        > >> Something doesn't sit right with me when a team tells an involved
                                        > >> PO to go away while they build the wrong thing. The fact that they
                                        > >> can correct it in the next iteration doesn't change the fact that
                                        > >> you're potentially building the wrong thing. The sooner you
                                        > >> discover this, the better.
                                        > >>
                                        > >> Mark
                                        > >>
                                        > >> --- In scrumdevelopment@yahoogroups.com, "SeanH" <seanh242@> wrote:
                                        > >> >
                                        > >> > I like this approach as well. Something doesn't sit right with
                                        > >> people suggesting there's no harm in empowering the PO to make
                                        > >> carte blanche changes over the course of the sprint. It can have a
                                        > >> suppressive effect on the team's creativity, and as reported by the
                                        > >> OP can kill team morale.
                                        > >> >
                                        > >> > Most likely, a month is too long for the business to wait for a
                                        > >> product increment, so reducing the duration of the sprint would
                                        > >> probably make the PO feel less compelled to butt into the team's
                                        > >> business on a daily basis.
                                        > >> >
                                        > >> > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
                                        > >> > >
                                        > >> > > The best way to deal with this is to shorten the iteration. So
                                        > >> go with one week or two week iterations and your PO can impact
                                        > >> changes more often. The other way of just accepting changes
                                        > >> mid-stream just undermines the teams commitment. I am not a
                                        > >> believer in always taking the hardline approach so if a change can
                                        > >> be negotiated in, in place of something else of equal size, I am
                                        > >> semi ok with that.
                                        > >> > >
                                        > >> > > Jack
                                        > >> > > www.agilebuddy.com
                                        > >> > > blog.agilebuddy.com
                                        > >> > >
                                        > >> > > --- In scrumdevelopment@yahoogroups.com, "Agnihotri Amit" <aagnihotri@> wrote:
                                        > >> > > >
                                        > >> > > > I am facing a problem in my project where we plan month-long
                                        > >> iterations. PO in my project is reviewing the work done on daily
                                        > >> basis and providing instant feedback that involves minor to major
                                        > >> changes and asking us to incorporate those changes within same
                                        > >> iteration. This is causing instability with the user stories,
                                        > >> design, code, test cases & planned iteration tasks & dates and
                                        > >> causing frustration amongst team members.
                                        > >> > > >
                                        > >> > > > How to address such situations? I would appreciate your views
                                        > >> on this.
                                        > >> > > >
                                        > >> > > > Regards,
                                        > >> > > > Amit Agnihotri
                                        >
                                      • Maurice le Rutte
                                        Op 12-8-2010 22:03, woynam schreef: I m currently serving as a PO for an internal, web-based application. The team deploys a build to our sandbox every night.
                                        Message 19 of 24 , Aug 24, 2010
                                        • 0 Attachment
                                          Op 12-8-2010 22:03, woynam schreef:
                                           

                                          I'm currently serving as a PO for an internal, web-based application. The team deploys a build to our sandbox every night. Each day I get to kick the tires, performing ad-hoc testing. There's nothing like getting working software every day to uncover potential issues. Most of the things we've uncovered so far were not considered during the initial planning for the iteration.

                                          Now, at times the team does get frustrated that things have "changed". Isn't this why we do agile? :-)

                                          If your team gets frustrated that things have changed, I wouldn't put down that remark with "that's why we do agile". To me agile doesn't mean "just code something and I'll see if I like it and ask you to redo it if not". I would like to have the frustration addressed in a retrospective and I would expect the PO to search together with the team for a better solution. Maybe you do, but that is not what I read here.

                                          In many cases it's the addition of new scenarios, and we add them (stories) to the backlog. However, if the new knowledge affects the current scenario/story, then we typically tackle it right now. I don't see much sense in ignoring the reality of the moment for the outdated view from the past.

                                          Assuming that your sprints are 2-4 weeks long I can't imagine which revolutionary new knowledge pops up that couldn't have been addressed during the sprint planning meeting. I have always found that a good Sprint II session helps the team to do the sprint effectively and build a shared picture of how we're going to do stuff, making close collaboration during the sprint possible.

                                          In particular, we use fairly low-fidelity mock ups during the feature discussions. Once we get the real software partially working, it's a lot easier to identify usability issues, and address them immediately.

                                          In a nutshell, it would be wonderful if everything could be nailed down during planning. Of course, I'd like to win the lottery, too, but it just ain't going to happen. As the customer proxy, I have to balance between order and chaos, knowing full well that changes will definitely affect the project "plan" in one way or another. But then again, that's why we continuously plan in agile projects.

                                          I guess where this is heading is toward continuous Scrum. The iteration boundaries are really only useful for measuring velocity, so we can get an idea of the overall length of the project. However, once the iteration starts, we're effectively running on one day sprints. When a team member is available, they grab the next ready story from the prioritized backlog. As long as the stories have enough detail to get started, and I'm available for Q&A, the story progresses until done, which is typically one to 3 days.

                                          I don't know what you mean with the 1-day sprints, I don't assume you close them with a review and retrospective, for example. It sounds more like kanban though than Scrum, which is fine by me. I do prefer the strategy of acceptance testing items as soon as they are done. I've written a blog article about it some time ago, for those who have reading skills for the Dutch language. I wouldn't want to wait until the end of a sprint to find out if the item is 'done' or not, if possible.

                                          Maurice.
                                          -- 
                                          http://www.scrummaster.nl / http://twitter.com/scrumnl
                                        • And Gon
                                          Hi, I completly agree with Maurice; it looks like you re doing Kanban where you also have general iterations where you agree with a goal to cover in the next
                                          Message 20 of 24 , Aug 25, 2010
                                          • 0 Attachment
                                            Hi,

                                            I completly agree with Maurice; it looks like you're doing Kanban where you also have general iterations where you agree with a goal to cover in the next iteration. I think this is as valid as any other thing and even more if it works well for you... and for the team.
                                            Maybe you're interested on reading "Kanban and Scrum - making the most of both"

                                            Regards,
                                            Andoni

                                            2010/8/24 Maurice le Rutte <maurice.lerutte@...>
                                             

                                            Op 12-8-2010 22:03, woynam schreef:

                                             

                                            I'm currently serving as a PO for an internal, web-based application. The team deploys a build to our sandbox every night. Each day I get to kick the tires, performing ad-hoc testing. There's nothing like getting working software every day to uncover potential issues. Most of the things we've uncovered so far were not considered during the initial planning for the iteration.

                                            Now, at times the team does get frustrated that things have "changed". Isn't this why we do agile? :-)

                                            If your team gets frustrated that things have changed, I wouldn't put down that remark with "that's why we do agile". To me agile doesn't mean "just code something and I'll see if I like it and ask you to redo it if not". I would like to have the frustration addressed in a retrospective and I would expect the PO to search together with the team for a better solution. Maybe you do, but that is not what I read here.

                                            In many cases it's the addition of new scenarios, and we add them (stories) to the backlog. However, if the new knowledge affects the current scenario/story, then we typically tackle it right now. I don't see much sense in ignoring the reality of the moment for the outdated view from the past.

                                            Assuming that your sprints are 2-4 weeks long I can't imagine which revolutionary new knowledge pops up that couldn't have been addressed during the sprint planning meeting. I have always found that a good Sprint II session helps the team to do the sprint effectively and build a shared picture of how we're going to do stuff, making close collaboration during the sprint possible.

                                            In particular, we use fairly low-fidelity mock ups during the feature discussions. Once we get the real software partially working, it's a lot easier to identify usability issues, and address them immediately.

                                            In a nutshell, it would be wonderful if everything could be nailed down during planning. Of course, I'd like to win the lottery, too, but it just ain't going to happen. As the customer proxy, I have to balance between order and chaos, knowing full well that changes will definitely affect the project "plan" in one way or another. But then again, that's why we continuously plan in agile projects.

                                            I guess where this is heading is toward continuous Scrum. The iteration boundaries are really only useful for measuring velocity, so we can get an idea of the overall length of the project. However, once the iteration starts, we're effectively running on one day sprints. When a team member is available, they grab the next ready story from the prioritized backlog. As long as the stories have enough detail to get started, and I'm available for Q&A, the story progresses until done, which is typically one to 3 days.

                                            I don't know what you mean with the 1-day sprints, I don't assume you close them with a review and retrospective, for example. It sounds more like kanban though than Scrum, which is fine by me. I do prefer the strategy of acceptance testing items as soon as they are done. I've written a blog article about it some time ago, for those who have reading skills for the Dutch language. I wouldn't want to wait until the end of a sprint to find out if the item is 'done' or not, if possible.

                                            Maurice.
                                            -- 
                                            http://www.scrummaster.nl / http://twitter.com/scrumnl




                                            --
                                            Andoni
                                            www.iatriple.net
                                          Your message has been successfully submitted and would be delivered to recipients shortly.