56596Why do we have to complete our sprint goal?
- Feb 17, 2013Hi 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 blockagesCan 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
- Next post in topic >>