Thursday, February 10, 2011

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" ('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.


  1. It is for me a very interesting blog post. I had in my team both over and undercommiting. The overcommiting causes some frustration at the end of the sprint, because we don't reach the goal. With undercommiting I had the problem, that the next story in the product backlog does not match from the available skill or from the remaining time in the sprint.

    So the my teams decided to create a sprint backlog with mandatory items (must have) and some optional items. So we had some items which are discussed with the team, estimated and which the product owner wants. So as soon we see that we have some capacity we start with this optional item. If we get it finished every one was happy. If the optional item at the end of the sprint wasn't "Done" that the frustration was not so high, the it was an optional item which we don't commit from beginning.

    So perhaps this approach will help you fill up the sprint backlog, that the team put a little bit more presure on itself, but on the other hand if the optional stories wouldn't be finished by the end of the sprint nobody is frustrated.

    I'm curious to read you opinion on my suggestion.

  2. Thanks for your comment! I personally don't believe in the idea of adding a "Mandatory"-"Not mandatory" dimension to story priorities. I think it is important to maintain a backlog that allows for _strict_ prioritization both in the sense that items have a unique priority relative to all other and in the sense that priority levels are always respected by the Scrum team.

    I think every Scrum teams need a culture of it being OK not to finish everything in the sprint always. After all, the team's committment at the beginning of the sprint is NOT "We promise to deliver the entire sprint backlog by the end of this sprint", but rather "Right now, we believe we are able to deliver the entire sprint backlog by the end of the sprint - and we promise we'll tell you as soon as this belief changes". Important difference.

    What I was trying to pinpoint in my blog post is what is problem of the psychological phenomenon commonly called Parkinson's Law; i.e. "Work expands so as to fill the time available for its completion". A scrum team that is aware of this and fills up every sprint will run less of a risk of generating "extra effort" (which is regarded as waste by the Lean Software Development philosophy).

  3. Maybe I have missed it in your article: The main problem with over commitment is that the TEAM has failed to deliver what they have committed; the reasons for this might be very different:

    - The ProductOwner has not been precise enough.
    - The TEAM has not asked enough details.
    - Not planned work were coming in (Bug's, ...)
    - Management changes priorities (yes, this happens)
    - TEAM member have problems with estimating
    - Problems with Build (other TEAM's)
    - Problems with Testenvironment
    - Dependency to another TEAM
    - ...

    Whether a TEAM "...need (and like) a healthy amount of stress/pressure..." sounds to me very directive. In Scrum the TEAM require to have the control over the quantity to be able to provide quality by ensuring all necessary steps as defined in the definition of done. If they finish earlier they can check whether they take time to improve, refactor things. Sometimes it's just to try something or to read articles and books. They also can define to take a further story when they believe they can do it.

  4. Maarit Laanti, Agile & Lean CoachOctober 20, 2011 at 5:36 PM

    I think the question is not about over- or undercommitment. If you constantly overcommit, you cause stress and unwanted behavior in the team, which will lead to health problems in the long run.
    If the team constantly undercommits, they will not feel responsible for the company - and your job as their manager would be to clarify the goal (i.e. make company successful).
    I think the point is to keep retrospectives and take one item to next sprint backlog that helpthe team to do the nect sprint better. This could be e.g. investment to continuous integration system, more effective communication, increase of automation... take a look on your value stream and decide what to improve. The point is, releasing good quality code should become easier sprint by sprint. That should end up in improved velocity (not faked one, by making user stories smaller and smaller but a real improvement) and a positive cycle of job satisfaction, motivation etc.

  5. Very Nice post! and well explained

  6. COEPD LLC- Center of Excellence for Professional Development is the most trusted online training platform to global participants. We are primarily a community of Business Analysts who have taken the initiative to facilitate professionals of IT or Non IT background with the finest quality training. Our trainings are delivered through interactive mode with illustrative scenarios, activities and case studies to help learners start a successful career. We impart knowledge keeping in view of the challenging situations individuals will face in the real time, so that they can handle their job deliverables with at most confidence.