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

Looking for ideas on how to handle stories that were not accepted.

Expand Messages
  • el_jeffe01
    I am interested in hearing how teams deal with stories that do not gain acceptance when the sprint ends. I have listed four options below but I am sure there
    Message 1 of 8 , Nov 21, 2008
    • 0 Attachment
      I am interested in hearing how teams deal with stories that do not
      gain acceptance when the sprint ends. I have listed four options
      below but I am sure there are more and I would like to hear this
      forums feedback on these options as well as any others that teams
      have tried.

      I would like to hear about both the good and the bad experiences with
      the different options so I can be prepared.

      Thanks for your feedback.

      Jeff

      Option 1:
      • No value is attributed to the work that was done during the
      sprint on the rejected story.
      • The story is moved to the backlog to be reprioritized by the
      product owner.
      • When the story is completed the team gets credit for the full
      value of the points
      o Plus's
       Accurately reflects delivered "business value" per Sprint
       Potentially forces teams to be more focused on only starting
      work that can be completed in a sprint


      o Minuses
       Does not account for work that was done and did deliver real
      value even if all requirements were not met.
       Can Skew the velocity tracking adding peaks and valleys


      Option 2:
      • No value is attributed to the work that was done during the
      sprint on the rejected story.
      • The story is resized to determine what is required to gain
      acceptance and moved to the backlog to be reprioritized by the
      product owner.
      • When the story is completed the team gets credit for the
      points in the "completion" story.
      o Plus's
       Potentially forces teams to be more focused on only starting
      work that can be completed in a sprint

      o Minuses
       Velocity is lost since team only gets credit for the smaller
      point value of the story



      Option 3:
      • A new story is created and sized to deliver what is required
      to gain acceptance of the original Story.
      • The new story is placed into the backlog to be reprioritized
      by the Product Owner.
      • The original Story is re-sized (Points assigned to the new
      story – original Points) to account for the value that was delivered
      during the sprint even though the overall story was rejected.
      • This reduced deliverable is accepted by the PO and the team
      is given credit for the points in current sprint.

      o Plus's
       More accurately measures velocity of the team

      o Minuses
       Could encourage team to take on more work than they can
      complete since this minimizes the impact of not delivering a story.

      Option 4:
      • A new story is created and sized to deliver what is required
      to gain acceptance.
      • The new story is placed into the backlog to be reprioritized
      by the Product Owner.
      • The original Story is re-sized (Points assigned to the new
      story – original Points) to account for the value that was delivered
      during the sprint even though the overall story was rejected.
      • The discounted story does not get acceptance until the new
      story gets acceptance.

      o Plus's
       More accurately measures velocity of the team
       Team does not get credit for work until it is fully completed

      o Minuses
       Could encourage team to take on more work than they can
      complete since this minimizes the impact of not delivering a story.
    • Mark Levison
      Quick answer - most people opt for option #1 - until the customer derives real business value from it no credit. That means peaks and valleys wrt velocity. We
      Message 2 of 8 , Nov 21, 2008
      • 0 Attachment
        Quick answer - most people opt for option #1 - until the customer derives real business value from it no credit. That means peaks and valleys wrt velocity. We solve that problem by using a trailing average for velocity (last three iterations).

        Must run - I have a coding dojo to start.

        Cheers
        Mark

        On Fri, Nov 21, 2008 at 1:18 PM, el_jeffe01 <jdmyers01@...> wrote:

        I am interested in hearing how teams deal with stories that do not
        gain acceptance when the sprint ends. I have listed four options
        below but I am sure there are more and I would like to hear this
        forums feedback on these options as well as any others that teams
        have tried.

        I would like to hear about both the good and the bad experiences with
        the different options so I can be prepared.

        Thanks for your feedback.

        Jeff

        Option 1:
        • No value is attributed to the work that was done during the
        sprint on the rejected story.
        • The story is moved to the backlog to be reprioritized by the
        product owner.
        • When the story is completed the team gets credit for the full
        value of the points
        o Plus's
        &#61607; Accurately reflects delivered "business value" per Sprint
        &#61607; Potentially forces teams to be more focused on only starting
        work that can be completed in a sprint

        o Minuses
        &#61607; Does not account for work that was done and did deliver real
        value even if all requirements were not met.
        &#61607; Can Skew the velocity tracking adding peaks and valleys

        Option 2:
        • No value is attributed to the work that was done during the
        sprint on the rejected story.
        • The story is resized to determine what is required to gain
        acceptance and moved to the backlog to be reprioritized by the
        product owner.
        • When the story is completed the team gets credit for the
        points in the "completion" story.
        o Plus's
        &#61607; Potentially forces teams to be more focused on only starting
        work that can be completed in a sprint

        o Minuses
        &#61607; Velocity is lost since team only gets credit for the smaller
        point value of the story

        Option 3:
        • A new story is created and sized to deliver what is required
        to gain acceptance of the original Story.
        • The new story is placed into the backlog to be reprioritized
        by the Product Owner.
        • The original Story is re-sized (Points assigned to the new
        story – original Points) to account for the value that was delivered
        during the sprint even though the overall story was rejected.
        • This reduced deliverable is accepted by the PO and the team
        is given credit for the points in current sprint.

        o Plus's
        &#61607; More accurately measures velocity of the team

        o Minuses
        &#61607; Could encourage team to take on more work than they can
        complete since this minimizes the impact of not delivering a story.

        Option 4:
        • A new story is created and sized to deliver what is required
        to gain acceptance.
        • The new story is placed into the backlog to be reprioritized
        by the Product Owner.
        • The original Story is re-sized (Points assigned to the new
        story – original Points) to account for the value that was delivered
        during the sprint even though the overall story was rejected.
        • The discounted story does not get acceptance until the new
        story gets acceptance.

        o Plus's
        &#61607; More accurately measures velocity of the team
        &#61607; Team does not get credit for work until it is fully completed

        o Minuses
        &#61607; Could encourage team to take on more work than they can
        complete since this minimizes the impact of not delivering a story.




        --
        Cheers
        Mark Levison
        Blog: http://www.notesfromatooluser.com/
        Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
        Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
      • Mark Summers
        Its got to be option 1, its good that the team don t get credit for unfinished work, it keeps them focused on getting work done. They will eventually get the
        Message 3 of 8 , Nov 21, 2008
        • 0 Attachment
          Its got to be option 1, its good that the team don't get credit for
          unfinished work, it keeps them focused on getting work done. They
          will eventually get the whole credit for the work and the velocity
          will balance out. The peaks and troughs don't matter its the
          velocity over time that is useful.

          Creating new stories is just going to add confusion. Of course it is
          a different matter if the story is done and somebdy thinks of an
          enhancement. The the team should get the credit, the story is
          considered done and a new story is created for the new work.

          --- In scrumdevelopment@yahoogroups.com, "el_jeffe01" <jdmyers01@...>
          wrote:
          >
          > I am interested in hearing how teams deal with stories that do not
          > gain acceptance when the sprint ends. I have listed four options
          > below but I am sure there are more and I would like to hear this
          > forums feedback on these options as well as any others that teams
          > have tried.
          >
          > I would like to hear about both the good and the bad experiences
          with
          > the different options so I can be prepared.
          >
          > Thanks for your feedback.
          >
          > Jeff
          >
          > Option 1:
          > • No value is attributed to the work that was done during the
          > sprint on the rejected story.
          > • The story is moved to the backlog to be reprioritized by the
          > product owner.
          > • When the story is completed the team gets credit for the full
          > value of the points
          > o Plus's
          >  Accurately reflects delivered "business value" per
          Sprint
          >  Potentially forces teams to be more focused on only
          starting
          > work that can be completed in a sprint
          >
          >
          > o Minuses
          >  Does not account for work that was done and did
          deliver real
          > value even if all requirements were not met.
          >  Can Skew the velocity tracking adding peaks and
          valleys
          >
          >
          > Option 2:
          > • No value is attributed to the work that was done during the
          > sprint on the rejected story.
          > • The story is resized to determine what is required to gain
          > acceptance and moved to the backlog to be reprioritized by the
          > product owner.
          > • When the story is completed the team gets credit for the
          > points in the "completion" story.
          > o Plus's
          >  Potentially forces teams to be more focused on only
          starting
          > work that can be completed in a sprint
          >
          > o Minuses
          >  Velocity is lost since team only gets credit for the
          smaller
          > point value of the story
          >
          >
          >
          > Option 3:
          > • A new story is created and sized to deliver what is required
          > to gain acceptance of the original Story.
          > • The new story is placed into the backlog to be reprioritized
          > by the Product Owner.
          > • The original Story is re-sized (Points assigned to the new
          > story – original Points) to account for the value that was
          delivered
          > during the sprint even though the overall story was rejected.
          > • This reduced deliverable is accepted by the PO and the team
          > is given credit for the points in current sprint.
          >
          > o Plus's
          >  More accurately measures velocity of the team
          >
          > o Minuses
          >  Could encourage team to take on more work than they
          can
          > complete since this minimizes the impact of not delivering a story.
          >
          > Option 4:
          > • A new story is created and sized to deliver what is required
          > to gain acceptance.
          > • The new story is placed into the backlog to be reprioritized
          > by the Product Owner.
          > • The original Story is re-sized (Points assigned to the new
          > story – original Points) to account for the value that was
          delivered
          > during the sprint even though the overall story was rejected.
          > • The discounted story does not get acceptance until the new
          > story gets acceptance.
          >
          > o Plus's
          >  More accurately measures velocity of the team
          >  Team does not get credit for work until it is fully
          completed
          >
          > o Minuses
          >  Could encourage team to take on more work than they
          can
          > complete since this minimizes the impact of not delivering a story.
          >
        • Oliver Seiler
          ... We ve tried using averaging to come up with our true velocity, but it didn t really stop us from over-committing. On our team we ve spent more time
          Message 4 of 8 , Nov 21, 2008
          • 0 Attachment
            On Fri, Nov 21, 2008 at 10:48 AM, Mark Levison <mark@...> wrote:
            > Quick answer - most people opt for option #1 - until the customer derives
            > real business value from it no credit. That means peaks and valleys wrt
            > velocity. We solve that problem by using a trailing average for velocity
            > (last three iterations).

            We've tried using averaging to come up with our "true" velocity, but
            it didn't really stop us from over-committing. On our team we've spent
            more time during sprint planning on really deciding how much we can
            commit too, rather than basing it in our velocity. This has helped
            three-fold:
            - We have few to no stories not done at the end of the sprint (though
            this still implies we are over-committing a bit)
            - The velocity has stabilized somewhat
            - We seem to have more slack available to focus on done-done, with I
            think better quality overall

            Stabilizing an otherwise highly-variable sprint to sprint velocity is,
            I think, an important goal, as the variability seems to indicate
            little-or-no slack available. Averaging the velocity winds up, I
            think, giving a velocity estimate that almost guarantees no slack, if
            used directly for sprint planning. The key for us was really making
            sure that we, the team, didn't feel like we were over-committing; that
            the plan seemed realistic. Or it least this is how it has worked out
            for us; using the velocity of the last sprint as a guide to this
            commitment seems to be working well so far.

            Cheers
            Oliver
          • George Dinwiddie
            Jeff, I agree with the other, so far. Definitely option 1. And as Oliver says, don t depend solely on velocity to determine what the team will attempt in the
            Message 5 of 8 , Nov 21, 2008
            • 0 Attachment
              Jeff,

              I agree with the other, so far. Definitely option 1. And as Oliver
              says, don't depend solely on velocity to determine what the team will
              attempt in the sprint. Back that up with an honest look at whether you
              can honestly commit to that amount (without padding to ensure you never
              fail).

              Some other comments below.

              el_jeffe01 wrote:
              > • When the story is completed the team gets credit for the full
              > value of the points

              I would try to lose this concept of "the team getting credit for the
              points." The points are there as an estimating tool, not for measuring
              the team. There is no credit. It's just a count.

              > o Plus's
              >  Accurately reflects delivered "business value" per Sprint

              Story points reflect effort, not value.

              >  Potentially forces teams to be more focused on only starting
              > work that can be completed in a sprint

              This is a very good thing. Ideally there will never be more than one
              story that has been started but not finished. Have as many people work
              on a story as can do so productively. If you find that only a few
              people can do so, such that you have many stories in progress in
              parallel, take that as an indication that there is more the team can
              learn about working together. It may be in the development practices,
              and it may be in the story definition. Or something else altogether.
              Reflect on it.

              >
              > o Minuses
              >  Does not account for work that was done and did deliver real
              > value even if all requirements were not met.

              If it delivered real value, then perhaps your stories are bigger than
              they should be. Try splitting them into thinner slices of
              functionality--each delivering a small increment of business value.

              >  Can Skew the velocity tracking adding peaks and valleys

              Many things can do this--not just unfinished stories. It's a good thing
              to notice and discuss in your retrospectives.

              Above all, remember that the goal is to create value for the
              business--not to collect story points for the team's velocity.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Petri Heiramo
              Hi, Very interesting discussions in this thread. I d have to go with #1, too, and actively speak against the other options. :) Done = Done, anything else is
              Message 6 of 8 , Nov 22, 2008
              • 0 Attachment
                Hi,


                Very interesting discussions in this thread.

                I'd have to go with #1, too, and actively speak against the other
                options. :)

                Done = Done, anything else is Not Done. It has to be simple to deliver
                the very simple message contained therein: only complete work is
                acceptable.

                Also, I would never recommend any team to base their commitment on
                their velocity. Not even on trailing or long-term average. Velocity is
                like weather. Just because it's sunny today, doesn't mean it will be
                tomorrow. It's only a planning tool to predict potential future,
                that's all.


                Yours,

                Petri Heiramo
                Process Development Manager, CSP
                Digia Plc., Finland


                --- In scrumdevelopment@yahoogroups.com, "el_jeffe01" <jdmyers01@...>
                wrote:
                >
                > I am interested in hearing how teams deal with stories that do not
                > gain acceptance when the sprint ends. I have listed four options
                > below but I am sure there are more and I would like to hear this
                > forums feedback on these options as well as any others that teams
                > have tried.
                >
                > I would like to hear about both the good and the bad experiences with
                > the different options so I can be prepared.
                >
                > Thanks for your feedback.
                >
                > Jeff
                >
                > Option 1:
                > • No value is attributed to the work that was done during the
                > sprint on the rejected story.
                > • The story is moved to the backlog to be reprioritized by the
                > product owner.
                > • When the story is completed the team gets credit for the full
                > value of the points
                > o Plus's
                >  Accurately reflects delivered "business value" per Sprint
                >  Potentially forces teams to be more focused on only starting
                > work that can be completed in a sprint
                >
                >
                > o Minuses
                >  Does not account for work that was done and did deliver real
                > value even if all requirements were not met.
                >  Can Skew the velocity tracking adding peaks and valleys
                >
                >
                > Option 2:
                > • No value is attributed to the work that was done during the
                > sprint on the rejected story.
                > • The story is resized to determine what is required to gain
                > acceptance and moved to the backlog to be reprioritized by the
                > product owner.
                > • When the story is completed the team gets credit for the
                > points in the "completion" story.
                > o Plus's
                >  Potentially forces teams to be more focused on only starting
                > work that can be completed in a sprint
                >
                > o Minuses
                >  Velocity is lost since team only gets credit for the smaller
                > point value of the story
                >
                >
                >
                > Option 3:
                > • A new story is created and sized to deliver what is required
                > to gain acceptance of the original Story.
                > • The new story is placed into the backlog to be reprioritized
                > by the Product Owner.
                > • The original Story is re-sized (Points assigned to the new
                > story – original Points) to account for the value that was delivered
                > during the sprint even though the overall story was rejected.
                > • This reduced deliverable is accepted by the PO and the team
                > is given credit for the points in current sprint.
                >
                > o Plus's
                >  More accurately measures velocity of the team
                >
                > o Minuses
                >  Could encourage team to take on more work than they can
                > complete since this minimizes the impact of not delivering a story.
                >
                > Option 4:
                > • A new story is created and sized to deliver what is required
                > to gain acceptance.
                > • The new story is placed into the backlog to be reprioritized
                > by the Product Owner.
                > • The original Story is re-sized (Points assigned to the new
                > story – original Points) to account for the value that was delivered
                > during the sprint even though the overall story was rejected.
                > • The discounted story does not get acceptance until the new
                > story gets acceptance.
                >
                > o Plus's
                >  More accurately measures velocity of the team
                >  Team does not get credit for work until it is fully completed
                >
                > o Minuses
                >  Could encourage team to take on more work than they can
                > complete since this minimizes the impact of not delivering a story.
                >
              • aalanatlas
                What *would* you recommend a team base its commitment on?
                Message 7 of 8 , Nov 24, 2008
                • 0 Attachment
                  What *would* you recommend a team base its commitment on?

                  --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
                  <petri.heiramo@...> wrote:
                  >
                  >[snip]
                  >
                  > Also, I would never recommend any team to base their commitment on
                  > their velocity. Not even on trailing or long-term average. Velocity is
                  > like weather. Just because it's sunny today, doesn't mean it will be
                  > tomorrow. It's only a planning tool to predict potential future,
                  > that's all.
                  >
                  >
                  > Yours,
                  >
                  > Petri Heiramo
                  > Process Development Manager, CSP
                  > Digia Plc., Finland
                  >
                  >
                  > --- In scrumdevelopment@yahoogroups.com, "el_jeffe01" <jdmyers01@>
                  > wrote:
                  > >
                  > > I am interested in hearing how teams deal with stories that do not
                  > > gain acceptance when the sprint ends. I have listed four options
                  > > below but I am sure there are more and I would like to hear this
                  > > forums feedback on these options as well as any others that teams
                  > > have tried.
                  > >
                  > > I would like to hear about both the good and the bad experiences with
                  > > the different options so I can be prepared.
                  > >
                  > > Thanks for your feedback.
                  > >
                  > > Jeff
                  > >
                  > > Option 1:
                  > > � No value is attributed to the work that was done during the
                  > > sprint on the rejected story.
                  > > � The story is moved to the backlog to be reprioritized by the
                  > > product owner.
                  > > � When the story is completed the team gets credit for the full
                  > > value of the points
                  > > o Plus's
                  > >  Accurately reflects delivered "business value" per Sprint
                  > >  Potentially forces teams to be more focused on only starting
                  > > work that can be completed in a sprint
                  > >
                  > >
                  > > o Minuses
                  > >  Does not account for work that was done and did deliver real
                  > > value even if all requirements were not met.
                  > >  Can Skew the velocity tracking adding peaks and valleys
                  > >
                  > >
                  > > Option 2:
                  > > � No value is attributed to the work that was done during the
                  > > sprint on the rejected story.
                  > > � The story is resized to determine what is required to gain
                  > > acceptance and moved to the backlog to be reprioritized by the
                  > > product owner.
                  > > � When the story is completed the team gets credit for the
                  > > points in the "completion" story.
                  > > o Plus's
                  > >  Potentially forces teams to be more focused on only starting
                  > > work that can be completed in a sprint
                  > >
                  > > o Minuses
                  > >  Velocity is lost since team only gets credit for the smaller
                  > > point value of the story
                  > >
                  > >
                  > >
                  > > Option 3:
                  > > � A new story is created and sized to deliver what is required
                  > > to gain acceptance of the original Story.
                  > > � The new story is placed into the backlog to be reprioritized
                  > > by the Product Owner.
                  > > � The original Story is re-sized (Points assigned to the new
                  > > story � original Points) to account for the value that was delivered
                  > > during the sprint even though the overall story was rejected.
                  > > � This reduced deliverable is accepted by the PO and the team
                  > > is given credit for the points in current sprint.
                  > >
                  > > o Plus's
                  > >  More accurately measures velocity of the team
                  > >
                  > > o Minuses
                  > >  Could encourage team to take on more work than they can
                  > > complete since this minimizes the impact of not delivering a story.
                  > >
                  > > Option 4:
                  > > � A new story is created and sized to deliver what is required
                  > > to gain acceptance.
                  > > � The new story is placed into the backlog to be reprioritized
                  > > by the Product Owner.
                  > > � The original Story is re-sized (Points assigned to the new
                  > > story � original Points) to account for the value that was delivered
                  > > during the sprint even though the overall story was rejected.
                  > > � The discounted story does not get acceptance until the new
                  > > story gets acceptance.
                  > >
                  > > o Plus's
                  > >  More accurately measures velocity of the team
                  > >  Team does not get credit for work until it is fully completed
                  > >
                  > > o Minuses
                  > >  Could encourage team to take on more work than they can
                  > > complete since this minimizes the impact of not delivering a story.
                  > >
                  >
                • Dan Rawsthorne
                  A team should base its commitment on the reality of the stories being asked for. This takes some actual thought, study, and collaboration by the team during
                  Message 8 of 8 , Nov 25, 2008
                  • 0 Attachment
                    A team should base its commitment on the reality of the stories being
                    asked for. This takes some actual thought, study, and collaboration by
                    the team during planning. In my opinion it probably requires .5-1 hour
                    per story to do a reasonable job. In other words, the commitment is
                    based on the team actually considering how they will get the job done -
                    actually planning, perhaps... Of course, the quality of the job is
                    tightly coupled to how solid the commitment is.

                    Dan Rawsthorne, PhD, CST
                    Senior Coach, Danube Technologies
                    dan@..., 425-269-8628



                    aalanatlas wrote:
                    >
                    > What *would* you recommend a team base its commitment on?
                    >
                    > --- In scrumdevelopment@yahoogroups.com
                    > <mailto:scrumdevelopment%40yahoogroups.com>, "Petri Heiramo"
                    > <petri.heiramo@...> wrote:
                    > >
                    > >[snip]
                    > >
                    > > Also, I would never recommend any team to base their commitment on
                    > > their velocity. Not even on trailing or long-term average. Velocity is
                    > > like weather. Just because it's sunny today, doesn't mean it will be
                    > > tomorrow. It's only a planning tool to predict potential future,
                    > > that's all.
                    > >
                    > >
                    > > Yours,
                    > >
                    > > Petri Heiramo
                    > > Process Development Manager, CSP
                    > > Digia Plc., Finland
                    > >
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com
                    > <mailto:scrumdevelopment%40yahoogroups.com>, "el_jeffe01" <jdmyers01@>
                    > > wrote:
                    > > >
                    > > > I am interested in hearing how teams deal with stories that do not
                    > > > gain acceptance when the sprint ends. I have listed four options
                    > > > below but I am sure there are more and I would like to hear this
                    > > > forums feedback on these options as well as any others that teams
                    > > > have tried.
                    > > >
                    > > > I would like to hear about both the good and the bad experiences with
                    > > > the different options so I can be prepared.
                    > > >
                    > > > Thanks for your feedback.
                    > > >
                    > > > Jeff
                    > > >
                    > > > Option 1:
                    > > > � No value is attributed to the work that was done during the
                    > > > sprint on the rejected story.
                    > > > � The story is moved to the backlog to be reprioritized by the
                    > > > product owner.
                    > > > � When the story is completed the team gets credit for the full
                    > > > value of the points
                    > > > o Plus's
                    > > >  Accurately reflects delivered "business value" per Sprint
                    > > >  Potentially forces teams to be more focused on only starting
                    > > > work that can be completed in a sprint
                    > > >
                    > > >
                    > > > o Minuses
                    > > >  Does not account for work that was done and did deliver real
                    > > > value even if all requirements were not met.
                    > > >  Can Skew the velocity tracking adding peaks and valleys
                    > > >
                    > > >
                    > > > Option 2:
                    > > > � No value is attributed to the work that was done during the
                    > > > sprint on the rejected story.
                    > > > � The story is resized to determine what is required to gain
                    > > > acceptance and moved to the backlog to be reprioritized by the
                    > > > product owner.
                    > > > � When the story is completed the team gets credit for the
                    > > > points in the "completion" story.
                    > > > o Plus's
                    > > >  Potentially forces teams to be more focused on only starting
                    > > > work that can be completed in a sprint
                    > > >
                    > > > o Minuses
                    > > >  Velocity is lost since team only gets credit for the smaller
                    > > > point value of the story
                    > > >
                    > > >
                    > > >
                    > > > Option 3:
                    > > > � A new story is created and sized to deliver what is required
                    > > > to gain acceptance of the original Story.
                    > > > � The new story is placed into the backlog to be reprioritized
                    > > > by the Product Owner.
                    > > > � The original Story is re-sized (Points assigned to the new
                    > > > story � original Points) to account for the value that was
                    > delivered
                    > > > during the sprint even though the overall story was rejected.
                    > > > � This reduced deliverable is accepted by the PO and the team
                    > > > is given credit for the points in current sprint.
                    > > >
                    > > > o Plus's
                    > > >  More accurately measures velocity of the team
                    > > >
                    > > > o Minuses
                    > > >  Could encourage team to take on more work than they can
                    > > > complete since this minimizes the impact of not delivering a story.
                    > > >
                    > > > Option 4:
                    > > > � A new story is created and sized to deliver what is required
                    > > > to gain acceptance.
                    > > > � The new story is placed into the backlog to be reprioritized
                    > > > by the Product Owner.
                    > > > � The original Story is re-sized (Points assigned to the new
                    > > > story � original Points) to account for the value that was
                    > delivered
                    > > > during the sprint even though the overall story was rejected.
                    > > > � The discounted story does not get acceptance until the new
                    > > > story gets acceptance.
                    > > >
                    > > > o Plus's
                    > > >  More accurately measures velocity of the team
                    > > >  Team does not get credit for work until it is fully completed
                    > > >
                    > > > o Minuses
                    > > >  Could encourage team to take on more work than they can
                    > > > complete since this minimizes the impact of not delivering a story.
                    > > >
                    > >
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.