Sprint Commitment
I'd like to get a feel about how other scrum teams define the word 'commitment'. When we 'commit' to a sprint, we define that as 'it will be done no matter what'. If that means working extra hours the last few days of the sprint, then that is what we do.
In talking to others, it seems like this is a bit of an outdated philosophy. The term 'forecast' is now being used? Maybe using a velocity range from the previous sprints?
The problem I have with our current definition of 'commitment' is that a basic philosophy of Agile is that humans are not good at estimating. If so, how can we 'commit' to an exact set of items to get done in a 2 week time frame for 7 people?
How do other scrum teams define 'commitment'? What do you do if not everything gets done in the sprint?
You are getting to the heart of why this word was replaced in the Scrum Guide. You can find some context to the change here (http://www.scrum.org/About/All-Articles/articleType/ArticleView/article…).
What do you do if not everything gets done in the sprint?
As soon as this situation becomes a possibility we make sure to inform those who care. Particularly the Product Owner so we can discuss our options.
We might also explore the why this occurred during our Retrospective (or any time really). This is particularly important if the current process and environment doesn't surface this information with an opportunity to make adjustments. For instance, if it only became clear in the last few days of the sprint that something might not be fully Done, what experiment can we come up with to surface this information more readily. It may be a simple gut check during the Daily Scrum or it may be a change to reduce serial task execution.
Either way, you are right on: we cannot avoid the Cone of Uncertainty even within the Sprint. For that reason, we do not use the word commitment with all of it's baggage.
Thanks for the comments, Ryan. I definitely agree that 1) as soon as we see that items may not be done in the sprint that we let the appropriate people know, and 2) discuss this in the retro to learn from it.
I agree with what Ryan said, and the only thing I would add is to watch out for carrying over lots of items. Sometimes(often, but not always) consistently carrying over more than 2 PBI's is a smell of something else that is not working well. (Examples: siloing, requirements churn, waterfall baggage, over committing, etc)
My guess is that our velocity will probably increase by going away from a hard commitment to a 'forecast'. I think it is human nature to lower your estimate if you are required to do a hard commitment. There is always that Cone Of Uncertainty in the back of your mind.
Be careful not to equate higher velocity with more value delivered. This
is an easy and common mistake.
------------------------------
From: ScrumForum@scrum.org
Sent: 11/14/2012 11:59 AM
To: ryan@echelontouch.com
Subject: RE: Sprint Commitment [00000209:00000672]
As Ryan Cromwell points out, you are getting to the heart of why this word was replaced in the Scrum Guide. It has been a controversial change because:
1) It raises serious questions about Commitment-Based Planning, how it can be done, and even if such techniques are appropriate at all. Alternatives such as Velocity Based planning are arguably less suitable for new teams when they haven't established a velocity yet.
2) It potentially makes the application of agile contracts harder. If a contractual view is taken of a Sprint (i.e. that a supplier will supply X within timebox Y) then reducing this to a forecast may result in perceived breaches of contract, or at least in increased risk from the POV of the customer. This is a hot topic and there is a fortune to be made by lawyers out of it.