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

PO causing iteration instability

Expand Messages
  • Agnihotri Amit
    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
    Message 1 of 24 , Aug 4, 2010
      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
    • Gary Brown
      Hello, Amit! ... I would allow it to happen, but note the impact to velocity, so you can plan future iterations appropriately. Encourage the team to
      Message 2 of 24 , Aug 4, 2010
        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.
      • Peter Stevens (calendar)
        ... Hi Amit, You might find this blog article helpful: Eight Strategies for Achieving the Scrum Sprint Commitment http://bit.ly/a0cxiZ A technique I have to be
        Message 3 of 24 , Aug 4, 2010
          "On 04.08.10 16:33, Agnihotri Amit 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

          Hi Amit,

          You might find this blog article helpful: Eight Strategies for Achieving the Scrum Sprint Commitment
          http://bit.ly/a0cxiZ

          A technique I have to be useful in situations like this is called "Defend against Scope Creep." Summarized (and adapted for your context):

          A common problem in the sprint is discovering "new" requirements during the course of the sprint.

          To prevent scope creep, agree on the scope during the sprint planning. If the P-O adds something to the  requirement which is not clearly part of the story, I report that to the product owner. He can the add it to the Product Backlog (not the story in the sprint) and decide what to do with it. I continue to implement the story as previously agreed.

          How do you identify what is in the story and what not? Two components define the story: 1) its title -- use a complete sentence, and 2) how do demonstrate it to the Product Owner at the end of the sprint. If the functionality in question is needed to make the title happen and is visible in the 'how to demo' work-flow, then it is part of the story, otherwise not.

          That was the short version, more detail in article.

          Hope this helps,

          Cheers,
          Peter
          -- 
          Lean Agile Scrum Konferenz in Zürich mit Mary Poppendieck und Henrik Kniberg.
          Schlagen Sie die Brücke von Scrum Team bis zum schlanken Unternehmen!
          http://bit.ly/las-zh 
          
          Peter Stevens, CSM, CSPO, CSP
          Independent Scrum Trainer and Coach
          Sierra-Charlie Consulting | Zurich | Switzerland
          
          Member of DasScrumTeam.de
          
          blog:  http://scrum-breakfast.com
          tel:   +41 44 586 6450 
          cell:  +41 79 422 6722
          skype: peterstev
        • woynam
          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
          Message 4 of 24 , Aug 4, 2010
            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
            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 5 of 24 , Aug 4, 2010
              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 6 of 24 , Aug 4, 2010
                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 7 of 24 , Aug 4, 2010
                  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 8 of 24 , Aug 4, 2010
                    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 9 of 24 , Aug 4, 2010
                      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 10 of 24 , Aug 5, 2010
                        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 11 of 24 , Aug 5, 2010
                          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 12 of 24 , Aug 6, 2010
                            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 13 of 24 , Aug 6, 2010
                              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 14 of 24 , Aug 6, 2010
                                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 15 of 24 , Aug 8, 2010
                                  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 16 of 24 , Aug 10, 2010
                                    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 17 of 24 , Aug 11, 2010
                                      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 18 of 24 , Aug 11, 2010
                                        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 19 of 24 , Aug 11, 2010
                                          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 20 of 24 , Aug 12, 2010
                                            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 21 of 24 , Aug 12, 2010
                                              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 22 of 24 , Aug 12, 2010
                                                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 23 of 24 , Aug 24, 2010
                                                  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 24 of 24 , Aug 25, 2010
                                                    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.