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

Re: dealing with emergencies

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