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 ArulMessage 1 of 9 , Feb 20View Source
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?
Albert Arul Prakash
Best answer yet to this question, IMO. I've been thinking it and waiting for it to come. Thanks.
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
--- 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
> * 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.