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

Re: [scrumdevelopment] Why do we have to complete our sprint goal?

Expand Messages
  • Cass Dalton
    The term Scrum comes from Rugby and is used because 1) the entire team acts as a single entity to move the ball down field and 2) the team completely resets in
    Message 1 of 9 , Feb 18, 2013
    • 0 Attachment

      The term Scrum comes from Rugby and is used because 1) the entire team acts as a single entity to move the ball down field and 2) the team completely resets in a scrum.  The latter is important because the complete reset gives the PO the ability to completely change direction on any sprint boundary.  This is what gives scrum its agility.  If you are letting items linger from one sprint to the next, you are degrading this agility.  But more importantly, the former means that the entire team is focused on a single objective or set of objectives.  If the team commits to a set of objectives and can never complete them all, they are losing focus.  Eventually there will be a perception problem to management that the team can never keep their promises and a morale problem within the team that they can never completely succeed.
      But most importantly, the feedback loop that occurs during the sprint review is tied closely to completing the sprint goals. Not meeting the goals is one of the first red flags that should be invoking a self improvement discussion.  At first, a team will frequently miss objectives. But they should be discussing why and fixing it.  Just like the reset helps the PO be agile, the inspect-and-adapt that comes from team introspection helps the team be agile.

      On Feb 18, 2013 1:57 AM, "Srinivas" <ceezone@...> wrote:
       

      Hello,
      Another perspective is that focus is diluted if there is a spillover. Since each sprint has a goal and team commitment is crucial; an item left out and being viewed as normal, simply masks the underlying problems of fragmented focus. One thing that can be done is to get better at breaking down user stories into smaller units. Then one can pick more number of smaller items and complete everything in a given sprint, as it is easier to fit the smaller stories into available capacity.

       Trust this is of some use.

      Cheers
      Srinivas


      Sent from my iPhoney

      On Feb 18, 2013, at 2:32 AM, Michael James <mj4scrum@...> wrote:

       

      A key reason is transparency.  When we have software that's not properly tested, no one can honestly say where we really are, as the FBI discovered:



      --mj
      (Michael)

      On Feb 17, 2013, at 6:14 AM, Greg Lucas-Smith <bwobbones@...> wrote:

       

      Hi all,

        I'm the Scrum Master for 3 Scrum teams and we've been working our way through the process for about 12 months now with great success.  Even our older-and-less-inclined-to-change team members are now on board and we're making great strides.  We're at the tail end of a 3 year product development and we're just about to finally release to our customer.

        I've made great headway in convincing the team and our management that a 3 year development cycle is not that great and that now we are developing in 2 week increments we should be releasing those.  Everyone is on board and I can now see that there would be some real benefit in ensuring that our sprint commitment is completed every time.  

        We haven't really been that successful in this regard, there always seems to be one or two items on the board that tick over into the next sprint.  For the last couple of sprints I've decided to make it a priority to reduce our planned commitment and we've been much better, missing only 2 of the 6 possible commitments.

        My problem is that I'm constantly hit with the subject question: Why?  What is the real value in making sure that all of the items in the commitment are "Done"?  If we do half the work and leave that work sitting in our local workspace, who cares if it doesn't make the end of the sprint?

        I have come up with a couple of answers for them, all of which they've found unsatisfying:

        * it feels good to know that you completed what you committed to ("feels good?  who cares?  I feel good when I'm constantly solving problems")
        * the product owner should feel comfortable to assume that we'll complete the commitment we set so he can start talking to the customer about our next release ("but the customers not here and won't know that we didn't complete everything")
        * a little time at the end of the sprint that is free for some developers allows investment by those developers in either the leftover sprint items or to spike upcoming backlog items ("there's only so much email I can check, wouldn't you rather I knocked out solutions instead?")
        
         Scanning old items in this list has found me a couple more:

        * working on something new before planning may find you working on something that the product owner may later de-prioritise
        * software is about discipline, this is a good way to inject and constantly remind ourselves of that
        * success is addictive and finishing the commitment regularly feels like success
        * allowing stories to span sprints removes the highlighting of blockages

        Can anyone think of any more?  I need to give the team reasons that a developer will appreciate, I'd like to say these things and have the team give me the AHA! look that I've seen with other aspects of the process.

      Greg
        
        


    • Jim Rice
      Greg,   Best answer yet to this question, IMO.  I ve been thinking it and waiting for it to come. Thanks.   Jim ________________________________ From:
      Message 2 of 9 , Feb 18, 2013
      • 0 Attachment
        Greg,
         
        Best answer yet to this question, IMO.  I've been thinking it and waiting for it to come. Thanks.
         
        Jim

        From: Steve <steve@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Monday, February 18, 2013 6:39 AM
        Subject: [scrumdevelopment] Re: Why do we have to complete our sprint goal?
         
        Hi Greg

        The commtiment that the team are asked to make is to a Sprint Goal not to the totallity of the user stories chosen.

        Think about the situation where you do commit to all the user stories; you have fixed time, fixed resource (cost) and fixed requirements. Remind you of anything? Yup - Waterfall!

        To illustrate a Sprint Goal - consider 'Enabling customer to pay for items'; this may involve US like 'Pay by Debit Card', 'Pay by Credit Card', Pay by PayPal, etc.

        Although the team may consider that implementing all payment methods is 'doable', they should only 'commit' to the most important ones, those that represent about 60%-65% of the estimated story points.

        If you make the goal too prescriptive, you will always have problems completing it (unless it is trivial).

        Some call this a commitment to the 'Minimum Marketable Features' (MMF) or the 'Minimum Value Product' (MVP).

        You will normally complete the MMF and also deliver some of the others; what is to be done with those youdo notcomplete should be discussed at the Sprint Review.

        Hope that helps

        Steve
        --- In mailto:scrumdevelopment%40yahoogroups.com, Greg Lucas-Smith wrote:
        >
        > Hi all,
        >
        > I'm the Scrum Master for 3 Scrum teams and we've been working our way
        > through the process for about 12 months now with great success. Even our
        > older-and-less-inclined-to-change team members are now on board and we're
        > making great strides. We're at the tail end of a 3 year product
        > development and we're just about to finally release to our customer.
        >
        > I've made great headway in convincing the team and our management that a
        > 3 year development cycle is not that great and that now we are developing
        > in 2 week increments we should be releasing those. Everyone is on board
        > and I can now see that there would be some real benefit in ensuring that
        > our sprint commitment is completed every time.
        >
        > We haven't really been that successful in this regard, there always seems
        > to be one or two items on the board that tick over into the next sprint.
        > For the last couple of sprints I've decided to make it a priority to
        > reduce our planned commitment and we've been much better, missing only 2 of
        > the 6 possible commitments.
        >
        > My problem is that I'm constantly hit with the subject question: Why?
        > What is the real value in making sure that all of the items in the
        > commitment are "Done"? If we do half the work and leave that work sitting
        > in our local workspace, who cares if it doesn't make the end of the sprint?
        >
        > I have come up with a couple of answers for them, all of which they've
        > found unsatisfying:
        >
        > * it feels good to know that you completed what you committed to ("feels
        > good? who cares? I feel good when I'm constantly solving problems")
        > * the product owner should feel comfortable to assume that we'll complete
        > the commitment we set so he can start talking to the customer about our
        > next release ("but the customers not here and won't know that we didn't
        > complete everything")
        > * a little time at the end of the sprint that is free for some developers
        > allows investment by those developers in either the leftover sprint items
        > or to spike upcoming backlog items ("there's only so much email I can
        > check, wouldn't you rather I knocked out solutions instead?")
        >
        > Scanning old items in this list has found me a couple more:
        >
        > * working on something new before planning may find you working on
        > something that the product owner may later de-prioritise
        > * software is about discipline, this is a good way to inject and
        > constantly remind ourselves of that
        > * success is addictive and finishing the commitment regularly feels like
        > success
        > * allowing stories to span sprints removes the highlighting of blockages
        >
        > Can anyone think of any more? I need to give the team reasons that a
        > developer will appreciate, I'd like to say these things and have the team
        > give me the AHA! look that I've seen with other aspects of the process.
        >
        > Greg
        >

      • Albert Arul Prakash
        Greg, Before I answer your question I would like to know from you about Why do you think we don’t have to complete our sprint goal? Thanks, Albert Arul
        Message 3 of 9 , Feb 20, 2013
        • 0 Attachment

          Greg,

           

          Before I answer your question I would like to know from you about

           

          Why do you think we don’t have to complete our sprint goal?

           

          Thanks,

          Albert Arul Prakash

           

          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jim Rice
          Sent: Monday, February 18, 2013 8:53 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Why do we have to complete our sprint goal?

           

           

          Greg,

           

          Best answer yet to this question, IMO.  I've been thinking it and waiting for it to come. Thanks.

           

          Jim

           

          From: Steve <steve@...>
          To: scrumdevelopment@yahoogroups.com
          Sent: Monday, February 18, 2013 6:39 AM
          Subject: [scrumdevelopment] Re: Why do we have to complete our sprint goal?

           

          Hi Greg

          The commtiment that the team are asked to make is to a Sprint Goal not to the totallity of the user stories chosen.

          Think about the situation where you do commit to all the user stories; you have fixed time, fixed resource (cost) and fixed requirements. Remind you of anything? Yup - Waterfall!

          To illustrate a Sprint Goal - consider 'Enabling customer to pay for items'; this may involve US like 'Pay by Debit Card', 'Pay by Credit Card', Pay by PayPal, etc.

          Although the team may consider that implementing all payment methods is 'doable', they should only 'commit' to the most important ones, those that represent about 60%-65% of the estimated story points.

          If you make the goal too prescriptive, you will always have problems completing it (unless it is trivial).

          Some call this a commitment to the 'Minimum Marketable Features' (MMF) or the 'Minimum Value Product' (MVP).

          You will normally complete the MMF and also deliver some of the others; what is to be done with those youdo notcomplete should be discussed at the Sprint Review.

          Hope that helps

          Steve

          --- In mailto:scrumdevelopment%40yahoogroups.com, Greg Lucas-Smith wrote:
          >
          > Hi all,
          >
          > I'm the Scrum Master for 3 Scrum teams and we've been working our way
          > through the process for about 12 months now with great success. Even our
          > older-and-less-inclined-to-change team members are now on board and we're
          > making great strides. We're at the tail end of a 3 year product
          > development and we're just about to finally release to our customer.
          >
          > I've made great headway in convincing the team and our management that a
          > 3 year development cycle is not that great and that now we are developing
          > in 2 week increments we should be releasing those. Everyone is on board
          > and I can now see that there would be some real benefit in ensuring that
          > our sprint commitment is completed every time.
          >
          > We haven't really been that successful in this regard, there always seems
          > to be one or two items on the board that tick over into the next sprint.
          > For the last couple of sprints I've decided to make it a priority to
          > reduce our planned commitment and we've been much better, missing only 2 of
          > the 6 possible commitments.
          >
          > My problem is that I'm constantly hit with the subject question: Why?
          > What is the real value in making sure that all of the items in the
          > commitment are "Done"? If we do half the work and leave that work sitting
          > in our local workspace, who cares if it doesn't make the end of the sprint?
          >
          > I have come up with a couple of answers for them, all of which they've
          > found unsatisfying:
          >
          > * it feels good to know that you completed what you committed to ("feels
          > good? who cares? I feel good when I'm constantly solving problems")
          > * the product owner should feel comfortable to assume that we'll complete
          > the commitment we set so he can start talking to the customer about our
          > next release ("but the customers not here and won't know that we didn't
          > complete everything")
          > * a little time at the end of the sprint that is free for some developers
          > allows investment by those developers in either the leftover sprint items
          > or to spike upcoming backlog items ("there's only so much email I can
          > check, wouldn't you rather I knocked out solutions instead?")
          >
          > Scanning old items in this list has found me a couple more:
          >
          > * working on something new before planning may find you working on
          > something that the product owner may later de-prioritise
          > * software is about discipline, this is a good way to inject and
          > constantly remind ourselves of that
          > * success is addictive and finishing the commitment regularly feels like
          > success
          > * allowing stories to span sprints removes the highlighting of blockages
          >
          > Can anyone think of any more? I need to give the team reasons that a
          > developer will appreciate, I'd like to say these things and have the team
          > give me the AHA! look that I've seen with other aspects of the process.
          >
          > Greg
          >

        Your message has been successfully submitted and would be delivered to recipients shortly.