56602Re: [scrumdevelopment] Why do we have to complete our sprint goal?
- Feb 18 3:18 AM
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.CheersSrinivas
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 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
- << Previous post in topic Next post in topic >>