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

dealing with emergencies

Expand Messages
  • Filipe Melo
    Im my company im a ScrumMaster and we are in Sprint #3, the duration of our sprints is 2 weeks. We work in a critical system already in production and
    Message 1 of 10 , Mar 30, 2008
    • 0 Attachment
      Im my company im a ScrumMaster and we are in Sprint #3, the duration
      of our sprints is 2 weeks.
      We work in a critical system already in production and sometimes some
      bugs or changes are required during the sprint. Which one are
      prioritised by PO before the actual user stories in the current
      sprint. In this case is imperative to us stop the current task and
      starts to working in emergencial change. My question is: How I deal
      with this emergencial tasks ? Nowadays I work in emergencial tasks and
      obviously i need to remove some story from the sprint backlog, but
      working in this way my velocity (in user story points) go down. Is
      correct add this changes "on the fly" in the sprint backlog and
      estimates points to it ? Or I should keep working in this way ?
      thanks !

      --
      Filipe
      "Programming today is a race between software engineers striving to
      build bigger and better idiot-proof programs, and the Universe trying
      to produce bigger and better idiots. So far, the Universe is winning."
      Rich Cook
    • jurgendesmet
      ... What you are actually saying is that you have to deal with impediments, it is normal that impediments bring down the teams velocity and thus your way of
      Message 2 of 10 , Mar 30, 2008
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Filipe Melo"
        <filipe.guelber@...> wrote:
        >
        > Im my company im a ScrumMaster and we are in Sprint #3, the duration
        > of our sprints is 2 weeks.
        > We work in a critical system already in production and sometimes some
        > bugs or changes are required during the sprint. Which one are
        > prioritised by PO before the actual user stories in the current
        > sprint. In this case is imperative to us stop the current task and
        > starts to working in emergencial change. My question is: How I deal
        > with this emergencial tasks ? Nowadays I work in emergencial tasks and
        > obviously i need to remove some story from the sprint backlog, but
        > working in this way my velocity (in user story points) go down. Is
        > correct add this changes "on the fly" in the sprint backlog and
        > estimates points to it ? Or I should keep working in this way ?
        > thanks !
        >
        > --
        > Filipe
        > "Programming today is a race between software engineers striving to
        > build bigger and better idiot-proof programs, and the Universe trying
        > to produce bigger and better idiots. So far, the Universe is winning."
        > Rich Cook
        >

        What you are actually saying is that you have to deal with
        impediments, it is normal that impediments bring down the teams
        velocity and thus your way of working is correct. That's just one of
        the clues of using scrum: making things visible that go wrong and take
        action to improve. You can use the burndown charts and dropping team
        velocity to show why you take action to avoid impediments in the future.

        Basically since you're working with short cycles "changes" as you call
        them should go by default into the next sprint and not disturb the
        ongoing work. If changes get in during the sprint this most probably
        points out that your product owner should do a better job and that you
        as a scrum master should come into the picture to put a hold on it.
        Also try to bring in your end users into the picture of developing new
        products, they will understand how it works and feel much comfortable
        at the end.

        Bugs are something different, these should indeed always be taken up
        asap after reconciliation by the PO. These will also bring down the
        teams velocity and there the impediment you have to handle is:
        quality. Best things to do in this case according to my experience is
        adding some of the XP techniques. As soon as quality is improving also
        this impediment will be less involved in your teams velocity and thus
        improve your process to deliver.

        Hope this was what you're looking for and I'm also looking forward to
        see how others deal with this. Definatly a topic to check out later on
        when there's more response.
      • Pascal Thivent
        I agree, the biggest problem I see is that you (or the PO) are changing the scope of the Sprint during the sprint and this is not recommended. If you or the PO
        Message 3 of 10 , Mar 30, 2008
        • 0 Attachment
          I agree, the biggest problem I see is that you (or the PO) are changing the scope of the Sprint during the sprint and this is not recommended. 
           
          If you or the PO think these emergency tasks will raise regularly, I would suggest to allocate some time for "production support" in each sprint and create an item (with story point estimate) in each sprint backlog. Use then this allocated time if emergency problem occur in production and add tasks (in hours) for them in the Sprint Backlog. If you don't need this time, just use it to fix the production code to avoid having emergency problems - or take an additional item from the Product Backlog. This way, your velocity will be more stable and facilitate the PO work (having the velocity going down because of impediments is not an issue in itself, the impediments are the issue).
           
          Having written this, I'm realizing there aren't much differences (taking items and removing some of them because of unplanned tasks VS taking items and some "optional" one if no unplanned tasks raise) and I feel a bit like changing the scope in both case. But still, I believe the second option would be better.
           
          WDYT ?
          On Mon, Mar 31, 2008 at 2:42 AM, jurgendesmet <jurgendesmet@...> wrote:

          --- In scrumdevelopment@yahoogroups.com, "Filipe Melo"


          <filipe.guelber@...> wrote:
          >
          > Im my company im a ScrumMaster and we are in Sprint #3, the duration
          > of our sprints is 2 weeks.
          > We work in a critical system already in production and sometimes some
          > bugs or changes are required during the sprint. Which one are
          > prioritised by PO before the actual user stories in the current
          > sprint. In this case is imperative to us stop the current task and
          > starts to working in emergencial change. My question is: How I deal
          > with this emergencial tasks ? Nowadays I work in emergencial tasks and
          > obviously i need to remove some story from the sprint backlog, but
          > working in this way my velocity (in user story points) go down. Is
          > correct add this changes "on the fly" in the sprint backlog and
          > estimates points to it ? Or I should keep working in this way ?
          > thanks !
          >
          > --
          > Filipe
          > "Programming today is a race between software engineers striving to
          > build bigger and better idiot-proof programs, and the Universe trying
          > to produce bigger and better idiots. So far, the Universe is winning."
          > Rich Cook
          >

          What you are actually saying is that you have to deal with
          impediments, it is normal that impediments bring down the teams
          velocity and thus your way of working is correct. That's just one of
          the clues of using scrum: making things visible that go wrong and take
          action to improve. You can use the burndown charts and dropping team
          velocity to show why you take action to avoid impediments in the future.

          Basically since you're working with short cycles "changes" as you call
          them should go by default into the next sprint and not disturb the
          ongoing work. If changes get in during the sprint this most probably
          points out that your product owner should do a better job and that you
          as a scrum master should come into the picture to put a hold on it.
          Also try to bring in your end users into the picture of developing new
          products, they will understand how it works and feel much comfortable
          at the end.

          Bugs are something different, these should indeed always be taken up
          asap after reconciliation by the PO. These will also bring down the
          teams velocity and there the impediment you have to handle is:
          quality. Best things to do in this case according to my experience is
          adding some of the XP techniques. As soon as quality is improving also
          this impediment will be less involved in your teams velocity and thus
          improve your process to deliver.

          Hope this was what you're looking for and I'm also looking forward to
          see how others deal with this. Definatly a topic to check out later on
          when there's more response.




          --
          Pascal
        • brett_a_bernstein
          One of the challenges for any scrummaster/scrum team is how to deal with something that it outside the scope of the sprint backlog. It represents change and
          Message 4 of 10 , Apr 1, 2008
          • 0 Attachment
            One of the challenges for any scrummaster/scrum team is how to deal
            with something that it outside the scope of the sprint backlog. It
            represents 'change' and I always found myself reminding my teams (a)
            that change is inevitable and (b) that scrum in part is designed to
            handle change.

            That having been said, I also tried to get the PO to do some up-front
            evaluation of the item. We were running 2 weeks sprints so if it came
            up in the middle of a sprint, on average, the soonest it could get
            finished would be the end of the next sprint in about 3 weeks

            [note: this assumes the item is small enough to do in a single sprint;
            we sometimes would devote 5-10 min after the daily stand to *briefly*
            discuss the item to determine this.]

            [note #2: the whole 1.5 x sprint length idea came from something I
            read written by Mike Cohn. If Mike had a dollar for every time I
            quoted that he would be a very, very happy camper. :)]

            The questions I asked were:

            To the team: 'Can this item be incorporated into the sprint commitment
            without giving up anything else?' If the item was small enough, the
            team usually had no issues. The key was asking the question in such a
            way that wasn't interpreted as an interruption (hence the 5-10 minute
            timebox). If it needed more then 5-10 minutes, odds are good it
            wasn't going to be something that could be slipped in.

            To the PO, assuming that the answer to the first question is 'no':
            'Can you wait 3 weeks for this or should we interrupt the current
            sprint?' I found that the good PO can explain why he/she can or cannot
            wait for the item.

            Side note ... this team had a good working relationship with its PO
            most of the time, but was confident enough in its abilities to push
            back when necessary.

            The PO also knew that they had the 'interrupt sprint right now' card
            in their pocket. He understood the power of this card and how
            expensive it was to play. He knew to only pull it out when things hit
            the proverbial fan.

            So my advice on your original question (how to deal with emergencies) is:

            a) try to shift the conversation around when the PO brings up an
            emergency. See what the team thinks about it (minimal time
            investment) and see if it really is a firedrill or if it is simply
            something that someone wants, but can wait till the next sprint for

            b) during retrospective look at the set of emergency items that came
            up and see if there are patterns. You might want to put in a user
            story that would help address some of those emergency items so the
            business unit can solve them without involving the implementation team
            directly. We got a lot of mileage out of this question and were able
            to eliminate certain items that previously had been 'emergencies'

            I freely admit that this approach violates the reciprocal commitments,
            but it was my attempt to balance the legit needs of the business vs.
            the legit needs of the team.

            Good Luck,

            Brett


            --- In scrumdevelopment@yahoogroups.com, "Pascal Thivent" <pascal@...>
            wrote:
            >
            > I agree, the biggest problem I see is that you (or the PO) are
            changing the
            > scope of the Sprint during the sprint and this is not recommended.
            >
            > If you or the PO think these emergency tasks will raise regularly, I
            would
            > suggest to allocate some time for "production support" in each
            sprint and
            > create an item (with story point estimate) in each sprint backlog.
            Use then
            > this allocated time if emergency problem occur in production and add
            tasks
            > (in hours) for them in the Sprint Backlog. If you don't need this
            time, just
            > use it to fix the production code to avoid having emergency problems
            - or
            > take an additional item from the Product Backlog. This way, your
            velocity
            > will be more stable and facilitate the PO work (having the velocity
            going
            > down because of impediments is not an issue in itself, the
            impediments are
            > the issue).
            >
            > Having written this, I'm realizing there aren't much differences (taking
            > items and removing some of them because of unplanned tasks VS taking
            items
            > and some "optional" one if no unplanned tasks raise) and I feel a
            bit like
            > changing the scope in both case. But still, I believe the second option
            > would be better.
            >
            > WDYT ?
            > On Mon, Mar 31, 2008 at 2:42 AM, jurgendesmet <jurgendesmet@...>
            > wrote:
            >
            > > --- In
            scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
            > > "Filipe Melo"
            > > <filipe.guelber@> wrote:
            > > >
            > > > Im my company im a ScrumMaster and we are in Sprint #3, the duration
            > > > of our sprints is 2 weeks.
            > > > We work in a critical system already in production and sometimes
            some
            > > > bugs or changes are required during the sprint. Which one are
            > > > prioritised by PO before the actual user stories in the current
            > > > sprint. In this case is imperative to us stop the current task and
            > > > starts to working in emergencial change. My question is: How I deal
            > > > with this emergencial tasks ? Nowadays I work in emergencial
            tasks and
            > > > obviously i need to remove some story from the sprint backlog, but
            > > > working in this way my velocity (in user story points) go down. Is
            > > > correct add this changes "on the fly" in the sprint backlog and
            > > > estimates points to it ? Or I should keep working in this way ?
            > > > thanks !
            > > >
            > > > --
            > > > Filipe
            > > > "Programming today is a race between software engineers striving to
            > > > build bigger and better idiot-proof programs, and the Universe
            trying
            > > > to produce bigger and better idiots. So far, the Universe is
            winning."
            > > > Rich Cook
            > > >
            > >
            > > What you are actually saying is that you have to deal with
            > > impediments, it is normal that impediments bring down the teams
            > > velocity and thus your way of working is correct. That's just one of
            > > the clues of using scrum: making things visible that go wrong and take
            > > action to improve. You can use the burndown charts and dropping team
            > > velocity to show why you take action to avoid impediments in the
            future.
            > >
            > > Basically since you're working with short cycles "changes" as you call
            > > them should go by default into the next sprint and not disturb the
            > > ongoing work. If changes get in during the sprint this most probably
            > > points out that your product owner should do a better job and that you
            > > as a scrum master should come into the picture to put a hold on it.
            > > Also try to bring in your end users into the picture of developing new
            > > products, they will understand how it works and feel much comfortable
            > > at the end.
            > >
            > > Bugs are something different, these should indeed always be taken up
            > > asap after reconciliation by the PO. These will also bring down the
            > > teams velocity and there the impediment you have to handle is:
            > > quality. Best things to do in this case according to my experience is
            > > adding some of the XP techniques. As soon as quality is improving also
            > > this impediment will be less involved in your teams velocity and thus
            > > improve your process to deliver.
            > >
            > > Hope this was what you're looking for and I'm also looking forward to
            > > see how others deal with this. Definatly a topic to check out later on
            > > when there's more response.
            > >
            > >
            > >
            >
            >
            >
            > --
            > Pascal
            >
          • Ada Gurman
            Does anyone have experience and lessons learned in implementing Agile in Matrix organization? ________________________________ From:
            Message 5 of 10 , Apr 1, 2008
            • 0 Attachment

              Does anyone have  experience and lessons learned in implementing Agile in Matrix organization?

               

               


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of brett_a_bernstein
              Sent: Tuesday, April 01, 2008 3:05 PM
              To: scrumdevelopment@yahoogroups.com
              Subject: [scrumdevelopment] Re: dealing with emergencies

               

              One of the challenges for any scrummaster/ scrum team is how to deal
              with something that it outside the scope of the sprint backlog. It
              represents 'change' and I always found myself reminding my teams (a)
              that change is inevitable and (b) that scrum in part is designed to
              handle change.

              That having been said, I also tried to get the PO to do some up-front
              evaluation of the item. We were running 2 weeks sprints so if it came
              up in the middle of a sprint, on average, the soonest it could get
              finished would be the end of the next sprint in about 3 weeks

              [note: this assumes the item is small enough to do in a single sprint;
              we sometimes would devote 5-10 min after the daily stand to *briefly*
              discuss the item to determine this.]

              [note #2: the whole 1.5 x sprint length idea came from something I
              read written by Mike Cohn. If Mike had a dollar for every time I
              quoted that he would be a very, very happy camper. :)]

              The questions I asked were:

              To the team: 'Can this item be incorporated into the sprint commitment
              without giving up anything else?' If the item was small enough, the
              team usually had no issues. The key was asking the question in such a
              way that wasn't interpreted as an interruption (hence the 5-10 minute
              timebox). If it needed more then 5-10 minutes, odds are good it
              wasn't going to be something that could be slipped in.

              To the PO , assuming that the answer to the first question is 'no':
              'Can you wait 3 weeks for this or should we interrupt the current
              sprint?' I found that the good PO can explain why he/she can or cannot
              wait for the item.

              Side note ... this team had a good working relationship with its PO
              most of the time, but was confident enough in its abilities to push
              back when necessary.

              The PO also knew that they had the 'interrupt sprint right now' card
              in their pocket. He understood the power of this card and how
              expensive it was to play. He knew to only pull it out when things hit
              the proverbial fan.

              So my advice on your original question (how to deal with emergencies) is:

              a) try to shift the conversation around when the PO brings up an
              emergency. See what the team thinks about it (minimal time
              investment) and see if it really is a firedrill or if it is simply
              something that someone wants, but can wait till the next sprint for

              b) during retrospective look at the set of emergency items that came
              up and see if there are patterns. You might want to put in a user
              story that would help address some of those emergency items so the
              business unit can solve them without involving the implementation team
              directly. We got a lot of mileage out of this question and were able
              to eliminate certain items that previously had been 'emergencies'

              I freely admit that this approach violates the reciprocal commitments,
              but it was my attempt to balance the legit needs of the business vs.
              the legit needs of the team.

              Good Luck,

              Brett

              --- In scrumdevelopment@ yahoogroups. com, "Pascal Thivent" <pascal@...>
              wrote:

              >
              > I agree, the biggest problem I see is that you (or the PO )
              are
              changing the
              > scope of the Sprint during the sprint and this is not recommended.
              >
              > If you or the PO think these emergency
              tasks will raise regularly, I
              would
              > suggest to allocate some time for "production support" in each
              sprint and
              > create an item (with story point estimate) in each sprint backlog.
              Use then
              > this allocated time if emergency problem occur in production and add
              tasks
              > (in hours) for them in the Sprint Backlog. If you don't need this
              time, just
              > use it to fix the production code to avoid having emergency problems
              - or
              > take an additional item from the Product Backlog. This way, your
              velocity
              > will be more stable and facilitate the PO
              work (having the velocity
              going
              > down because of impediments is not an issue in itself, the
              impediments are
              > the issue).
              >
              > Having written this, I'm realizing there aren't much differences (taking
              > items and removing some of them because of unplanned tasks VS taking
              items
              > and some "optional" one if no unplanned tasks raise) and I feel
              a
              bit like
              > changing the scope in both case. But still, I believe the second option
              > would be better.
              >
              > WDYT ?
              > On Mon, Mar 31, 2008 at 2:42 AM, jurgendesmet <jurgendesmet@ ...>
              > wrote:
              >
              > > --- In
              scrumdevelopment@ yahoogroups. com<scrumdevelopment% 40yahoogroups. com>,
              > > "Filipe Melo"
              > > <filipe.guelber@ > wrote:
              > > >
              > > > Im my company im a ScrumMaster and we are in Sprint #3, the
              duration
              > > > of our sprints is 2 weeks.
              > > > We work in a critical system already in production and sometimes
              some
              > > > bugs or changes are required during the sprint. Which one are
              > > > prioritised by PO before the
              actual user stories in the current
              > > > sprint. In this case is imperative to us stop the current task
              and
              > > > starts to working in emergencial change. My question is: How I
              deal
              > > > with this emergencial tasks ? Nowadays I work in emergencial
              tasks and
              > > > obviously i need to remove some story from the sprint backlog,
              but
              > > > working in this way my velocity (in user story points) go down.
              Is
              > > > correct add this changes "on the fly" in the sprint
              backlog and
              > > > estimates points to it ? Or I should keep working in this way ?
              > > > thanks !
              > > >
              > > > --
              > > > Filipe
              > > > "Programming today is a race between software engineers
              striving to
              > > > build bigger and better idiot-proof programs, and the Universe
              trying
              > > > to produce bigger and better idiots. So far, the Universe is
              winning."
              > > > Rich Cook
              > > >
              > >
              > > What you are actually saying is that you have to deal with
              > > impediments, it is normal that impediments bring down the teams
              > > velocity and thus your way of working is correct. That's just one of
              > > the clues of using scrum: making things visible that go wrong and
              take
              > > action to improve. You can use the burndown charts and dropping team
              > > velocity to show why you take action to avoid impediments in the
              future.
              > >
              > > Basically since you're working with short cycles "changes"
              as you call
              > > them should go by default into the next sprint and not disturb the
              > > ongoing work. If changes get in during the sprint this most probably
              > > points out that your product owner should do a better job and that
              you
              > > as a scrum master should come into the picture to put a hold on it.
              > > Also try to bring in your end users into the picture of developing
              new
              > > products, they will understand how it works and feel much comfortable
              > > at the end.
              > >
              > > Bugs are something different, these should indeed always be taken up
              > > asap after reconciliation by the PO .
              These will also bring down the
              > > teams velocity and there the impediment you have to handle is:
              > > quality. Best things to do in this case according to my experience is
              > > adding some of the XP techniques. As soon as quality is improving
              also
              > > this impediment will be less involved in your teams velocity and thus
              > > improve your process to deliver.
              > >
              > > Hope this was what you're looking for and I'm also looking forward to
              > > see how others deal with this. Definatly a topic to check out later
              on
              > > when there's more response.
              > >
              > >
              > >
              >
              >
              >
              > --
              > Pascal
              >

            • Dmitry Beransky
              On Tue, Apr 1, 2008 at 12:05 PM, brett_a_bernstein ... To Brett, or anyone else who can answer. I m still shaky on this whole notion of interrupting a sprint.
              Message 6 of 10 , Apr 1, 2008
              • 0 Attachment
                On Tue, Apr 1, 2008 at 12:05 PM, brett_a_bernstein
                <brett.a.bernstein@...> wrote:
                > To the PO, assuming that the answer to the first question is 'no':
                > 'Can you wait 3 weeks for this or should we interrupt the current
                > sprint?' I found that the good PO can explain why he/she can or cannot
                > wait for the item.

                To Brett, or anyone else who can answer. I'm still shaky on this
                whole notion of interrupting a sprint. I understand what purpose it
                theoretically serves, but practically... Let's have a hypothetical
                where the new item requires 4 hours to implement. Obviously, it's an
                interruption (disruption) to the sprint. Let's say the PO chooses to
                break the sprint. What exactly does this mean? That we have to sit
                down and estimate this new user story, find an exiting user story in
                the sprint backlog and replace it with the new? So at most this will
                take 3 hours to do (and this is a very generous estimate). Then we'll
                continue the sprint pretty much from where we left off, right?

                All we've lost is 3 hours for replanning. What I don't understand, is
                how this such a horrible thing that is supposed to deter the PO from
                making changes in a middle of a sprint? What am I missing?


                Dmitry
              • Tom Hume
                Out of interest... what would happen is this card were played? Would the PO and the team not gather, replan the sprint exactly as they had before but with A.N.
                Message 7 of 10 , Apr 1, 2008
                • 0 Attachment
                  Out of interest... what would happen is this card were played? Would
                  the PO and the team not gather, replan the sprint exactly as they had
                  before but with A.N. New-Item inserted and another item removed?

                  I get that shifting priorities mid-sprint and/or adding work after the
                  team has committed is bad, but how strong is the disincentive to
                  interrupt the sprint in this case?

                  On 1 Apr 2008, at 21:05, brett_a_bernstein wrote:
                  > The PO also knew that they had the 'interrupt sprint right now' card
                  > in their pocket. He understood the power of this card and how
                  > expensive it was to play. He knew to only pull it out when things hit
                  > the proverbial fan.

                  --
                  Future Platforms Ltd
                  e: Tom.Hume@...
                  t: +44 (0) 1273 819038
                  m: +44 (0) 7971 781422
                  company: www.futureplatforms.com
                  personal: tomhume.org
                • Jaideep Khanduja
                  Hi to all, I need some help on redefining my company processes in context to software projects - how agile/scrum would deal with following in relation to team
                  Message 8 of 10 , Apr 1, 2008
                  • 0 Attachment

                    Hi to all,

                     

                    I need some help on redefining my company processes in context to software projects – how agile/scrum would deal with following in relation to team formation, team size, transparency, story boards, sharing, progress etc.:

                    1. business study/ scope freezing/ customer consent/ sign off documents/ team values

                    2. product development / sizing/ members/ PO / scrum master/ management/ monitoring/ involvement/ time frame/ progress

                    3. testing and QA/QC involvement/ role

                    4. implementation/ trainings at customer site (international)/ sign offs

                    5. post implementation support

                     

                    As there are excellent people present on the board (this group), having clear knowledge on the subject, valuable inputs will help me in redefining/ re-engineering/ convincing management to handle these processes.

                     

                    Issues I am facing right now:

                    1. scattered groups
                    2. not all concerned are involved
                    3. biased/framed/wrong reporting/ projections that effects the complete cycle
                    4. person based perceptions/ projections
                    5. QA’s role starts at a later stage
                    6. improper handling of projects

                     

                    Best Regards,

                     

                    Jaideep

                    ___________________________________

                     

                    Thought of the day:  "If you believe that you know the requirements better than the customer, you are part of the problem, not the solution."

                    -Alan M. Davis

                    ___________________________________

                    P Please consider the environment before printing this e-mail


                    From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Dmitry Beransky
                    Sent: 02 April, 2008 02:38
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Re: dealing with emergencies

                     

                    On Tue, Apr 1, 2008 at 12:05 PM , brett_a_bernstein
                    <brett.a.bernstein@ gmail.com> wrote:

                    > To the PO , assuming that the answer to
                    the first question is 'no':
                    > 'Can you wait 3 weeks for this or should we interrupt the current
                    > sprint?' I found that the good PO can
                    explain why he/she can or cannot
                    > wait for the item.

                    To Brett , or anyone else who can answer. I'm still shaky on this
                    whole notion of interrupting a sprint. I understand what purpose it
                    theoretically serves, but practically. .. Let's have a hypothetical
                    where the new item requires 4 hours to implement. Obviously, it's an
                    interruption (disruption) to the sprint. Let's say the PO chooses to
                    break the sprint. What exactly does this mean? That we have to sit
                    down and estimate this new user story, find an exiting user story in
                    the sprint backlog and replace it with the new? So at most this will
                    take 3 hours to do (and this is a very generous estimate). Then we'll
                    continue the sprint pretty much from where we left off, right?

                    All we've lost is 3 hours for replanning. What I don't understand, is
                    how this such a horrible thing that is supposed to deter the PO from
                    making changes in a middle of a sprint? What am I missing?

                    Dmitry

                    Confidentiality Notice:

                    The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at admin@... immediately and destroy all the copies of this message and any attachments

                  • brett_a_bernstein
                    I probably could have provided more detail on the interrupt sprint card ... sorry ... here is a second attempt ... The reciprocal commitments I mentioned in
                    Message 9 of 10 , Apr 2, 2008
                    • 0 Attachment
                      I probably could have provided more detail on the 'interrupt sprint
                      card' ... sorry ... here is a second attempt ...

                      The reciprocal commitments I mentioned in my last post are pretty
                      important IMO to the success of any agile methodology. The team
                      commits to a set amount of work. The PO commits to not changing his
                      mind about the work he/she requested for the duration of the sprint.
                      The value in these dual commitments is that it attempts to eliminate
                      what I will call 'interruption-driven-development'. If your team is
                      running 4 week sprints and the PO keeps changing his/her mind, then I
                      would suggest you consider shorter sprints.

                      The card for this team could also be described as 'blow up the current
                      sprint' since the PO was basically saying that the sprint backlog as
                      defined no longer provided the business value needed at the time. In
                      short, if this card was played, the new item was big enough that
                      things were going to change more then this one item. I recall this
                      card being played only 2-3 times over 2 years and each time it was
                      played the explanation as to why it was being played got the
                      implementation team on board to re-plan.

                      Did this team at times accept swapping-in a new item and swapping-out
                      an without fully re-planning? Yes, as I said, we were trying to be
                      pragmatic. The key was the brief conversation about the item. If it
                      was really small (eg we have new disclaimer copy from the client), it
                      wasn't a big deal. I recall this happening in some way/shape/form
                      nearly every sprint. Sometimes it was easy. Sometimes there was
                      pushback/grumbling.

                      Did this always work smoothly? Hell no. I think this is one of the
                      tougher day-to-day challenges that SMs face. Did it work better then
                      what had happened before we started using scrum? Hell yes.

                      To sum things up ...There is a difference between blowing up a sprint
                      and giving the PO a helping hand on something. Communication and
                      transparency are important. As SM, I was trying to balance the
                      legitimate request of the business with the desire o the team to
                      finish the work they started. Part of my role was to protect the team
                      from outside forces (interruptions) and from itself (not being willing
                      to inspect and adapt).



                      --- In scrumdevelopment@yahoogroups.com, Tom Hume <Tom.Hume@...> wrote:
                      >
                      > Out of interest... what would happen is this card were played? Would
                      > the PO and the team not gather, replan the sprint exactly as they had
                      > before but with A.N. New-Item inserted and another item removed?
                      >
                      > I get that shifting priorities mid-sprint and/or adding work after the
                      > team has committed is bad, but how strong is the disincentive to
                      > interrupt the sprint in this case?
                      >
                      > On 1 Apr 2008, at 21:05, brett_a_bernstein wrote:
                      > > The PO also knew that they had the 'interrupt sprint right now' card
                      > > in their pocket. He understood the power of this card and how
                      > > expensive it was to play. He knew to only pull it out when things hit
                      > > the proverbial fan.
                      >
                      > --
                      > Future Platforms Ltd
                      > e: Tom.Hume@...
                      > t: +44 (0) 1273 819038
                      > m: +44 (0) 7971 781422
                      > company: www.futureplatforms.com
                      > personal: tomhume.org
                      >
                    • Peter Hundermark
                      I agree with Brett s comments. The team is there to do what the PO asks. And when the environment changes, they must adapt, even during the sprint. A good PO
                      Message 10 of 10 , Apr 2, 2008
                      • 0 Attachment
                        I agree with Brett's comments. The team is there to do what the PO asks.
                        And when the environment changes, they must adapt, even during the
                        sprint. A good PO will minimise the impact by prioritising carefully. A
                        good team will improve its process and quality, if this is a
                        contributing cause. A good SM will catalyse this.

                        Peter
                        CSC

                        --- In scrumdevelopment@yahoogroups.com, "brett_a_bernstein"
                        <brett.a.bernstein@...> wrote:
                        >
                        > I probably could have provided more detail on the 'interrupt sprint
                        > card' ... sorry ... here is a second attempt ...
                        >
                        > The reciprocal commitments I mentioned in my last post are pretty
                        > important IMO to the success of any agile methodology. The team
                        > commits to a set amount of work. The PO commits to not changing his
                        > mind about the work he/she requested for the duration of the sprint.
                        > The value in these dual commitments is that it attempts to eliminate
                        > what I will call 'interruption-driven-development'. If your team is
                        > running 4 week sprints and the PO keeps changing his/her mind, then I
                        > would suggest you consider shorter sprints.
                        >
                        > The card for this team could also be described as 'blow up the current
                        > sprint' since the PO was basically saying that the sprint backlog as
                        > defined no longer provided the business value needed at the time. In
                        > short, if this card was played, the new item was big enough that
                        > things were going to change more then this one item. I recall this
                        > card being played only 2-3 times over 2 years and each time it was
                        > played the explanation as to why it was being played got the
                        > implementation team on board to re-plan.
                        >
                        > Did this team at times accept swapping-in a new item and swapping-out
                        > an without fully re-planning? Yes, as I said, we were trying to be
                        > pragmatic. The key was the brief conversation about the item. If it
                        > was really small (eg we have new disclaimer copy from the client), it
                        > wasn't a big deal. I recall this happening in some way/shape/form
                        > nearly every sprint. Sometimes it was easy. Sometimes there was
                        > pushback/grumbling.
                        >
                        > Did this always work smoothly? Hell no. I think this is one of the
                        > tougher day-to-day challenges that SMs face. Did it work better then
                        > what had happened before we started using scrum? Hell yes.
                        >
                        > To sum things up ...There is a difference between blowing up a sprint
                        > and giving the PO a helping hand on something. Communication and
                        > transparency are important. As SM, I was trying to balance the
                        > legitimate request of the business with the desire o the team to
                        > finish the work they started. Part of my role was to protect the team
                        > from outside forces (interruptions) and from itself (not being willing
                        > to inspect and adapt).
                        >
                        >
                        >
                        > --- In scrumdevelopment@yahoogroups.com, Tom Hume Tom.Hume@ wrote:
                        > >
                        > > Out of interest... what would happen is this card were played? Would
                        > > the PO and the team not gather, replan the sprint exactly as they
                        had
                        > > before but with A.N. New-Item inserted and another item removed?
                        > >
                        > > I get that shifting priorities mid-sprint and/or adding work after
                        the
                        > > team has committed is bad, but how strong is the disincentive to
                        > > interrupt the sprint in this case?
                        > >
                        > > On 1 Apr 2008, at 21:05, brett_a_bernstein wrote:
                        > > > The PO also knew that they had the 'interrupt sprint right now'
                        card
                        > > > in their pocket. He understood the power of this card and how
                        > > > expensive it was to play. He knew to only pull it out when things
                        hit
                        > > > the proverbial fan.
                        > >
                        > > --
                        > > Future Platforms Ltd
                        > > e: Tom.Hume@
                        > > t: +44 (0) 1273 819038
                        > > m: +44 (0) 7971 781422
                        > > company: www.futureplatforms.com
                        > > personal: tomhume.org
                        > >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.