Overcommitment is better than undercommittment

This time I want to talk about the amount of user stories that a scrum team decide they feel comfortable committing to at the beginning of a sprint (at spring planning) - and what happens when they're approach the end of the sprint.

At sprint planning, have you ever had a discussion with (or in) your team about whether or not to include that last story or not in the sprint backlog? The one that they're unsure they'll be able to complete. What did you/they decide, and why? Did you hear anyone say something like "Well, let's stick with these fewer stories - we can always include that other one later during the sprint, if we should find ourselves with time to spare"?

If the team undercommits, i.e. includes a set of user stories that sums up to a lesser scope (a smaller sprint backlog), it means that they're reasonably likely to complete all stories committed to - and at the end of the sprint they have a good chance of getting a feeling of accomplishment and success. They delivered all the stories! Yay! And, as indicated by the quote above, they can always add that extra story at the end of the sprint if they complete the committed sprint backlog early. Right?

Constant overcommitment - on the other hand - might cause a feeling of failure, as the team never really manage to deliver what they commit to.

But, to be honest, how often has your team found themselves with time to spare at the end of a sprint? And how many times have they included that extra story from the top of the backlog at the end of the sprint? Somehow, the time available in a sprint always seem to be just enough for exactly (or less than) those stories committed to at the sprint planning - rarely more.

While I think we need to recognize and respect the potential negative consequences of constant failure by constant overcommittment, I think we also need to remember that people often need (and like) a healthy amount of stress/pressure in order for them not risk producing waste by extra effort (refer to Lean Software Development for more information about extra effort and waste).

The Agile approach is of course to try both alternatives a couple of times, and then inspect and adapt. Find out what suits your team(s). In my personal preference, however, I think reasonable overcommitment carries greater benefits than drawbacks.

Either way, the team owns the decision. It's their commitment. I for one want to remind my teams about and get them thinking about this for themselves. Keep it in mind at sprint planning.

There is a name of this phenomenon: Parkinson's Law; "Work expands so as to fill the time available for its completion" (http://en.wikipedia.org/wiki/Parkinson's_law).

Another approach used by some, is to not expect the team to include more stories during a sprint even if they finish early. As a general rule. The thinking behind that practice is that the team's commitment at the beginning of a sprint is what they agree on with the scrum product owner. And since that's what the scrum product owner expects, that's what is enough to deliver. Any spare time at the end of the sprint is used for other things; anything from free time (off work), lab activities, or whatever other fun things you could think of.

I think this approach is excellent in theory, and it sure sounds nice; if you finish early, you can go home. However as a general rule, in practice, when a deadline is approaching and you want to get as far as you can down the product backlog, i doubt that it would be possible to stick to this. Let me know if this works for you. I'm curious!

And as always, please give me some feedback. Let me know how you think about and handle this.