BT

Over-Commitment Versus Over-Delivery

by Vikas Hazrati on Jan 13, 2009 |

A major goal of sprint planning is to make a commitment to 'what is intended to be delivered' by the end of the sprint. Once, a commitment is made the team works together to achieve the goals. The Scrum master removes any impediments which would slow down the velocity of the team. Ideally, the team should meet its commitments, however, if the team is consistently over-committing or over-delivering then there is a cause for concern.

Over-commitment implies that the team cannot deliver. It means that the team is committing to more work than it can deliver and eventually fails in the commitment. Consistently over-committing would imply that either the team is unable to notice their velocity or external factors motivate the team to over-commit.

In a discussion on Scrum Development group Dave Milner mentioned,

Management intervention of this sort (i.e. demanding "commitment" to finishing all sprint tasks) just amplifies this situation. The bounce-back from over-committing to under-committing will be extreme.

Over-commitment leads to failures and a dip in the morale of the team. Jeff Heinen mentioned,

A team that enters a sprint, knowing that there's no way they can achieve everything they've taken on, isn't really committed. They aren't self-organizing to achieve goals, but rather scrambling to pack as much in as they can.

Ken Schwaber mentioned Over-commitment as a strong smell,

Teams overcommitting after the third sprint is a smell that they are not managing themselves. I’ll bet they don’t have an accurate sprint backlog that they are updating, and I’ll bet that you don’t hear a group of people figuring out how they are going to meet their sprint goal every daily scrum.

Over-delivery on the other hand implies that the team cannot commit. Though it may sound good, however if a team is consistently over delivering then it means that they are under-committing. Jim Schiel suggested,

How much your team is willing to commit to during any Sprint is going to depend on a lot of things, starting with how comfortable your team is with not achieving all of the planned results. Many Scrum teams will deliberately under-commit because they work (or are under the impression that they work) in an environment that frowns on not achieving their objectives as stated.

Jim mentioned that the way to deal with over-delivery is to provide an environment to the teams which encourages achievable, aggressive commitments and does not penalize the teams for not achieving the results. According to him, teams should be encouraged to be aggressive with their commitments during Sprint Planning and to continuously take steps to improve team performance.

Most Agilists on various forums believed that commitment should be left to the teams and should be free from any external influences. Alistair Cockburn added that once the choice is left to teams, it is a personal preference of the teams to decide what motivates them, he gave an interesting example,

I visited two teams almost back to back, and one of them said, We like it when we deliver everything we said we would. We find it discouraging when there is always more on the list than we can accomplish .... and the next one said, We prefer it when there is more on the list than we can get through. That way we never have to wonder what to do next - there is always something there waiting to get picked up.

Thus though both Over-commitment and Over-delivery sound like smells, however, it boils down to what the team is comfortable with. In Ron Jeffries’ words,

Your problem isn't productivity, in my opinion. It is predictability.

If predictability is one of the essential traits that a team is looking to master then it needs to walk a fine line between Over-committing and Over-delivering.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Commitment versus Estimation by Kerry Buckley

Personally I prefer to estimate what can be delivered in an iteration, rather than commit to it. Committing implies a false certainty about accuracy, and masks the fact that the agreed scope is no more than an estimate (unless the team are secretly building-in massive padding to their story sizing).

As long as iterations are short and result in delivery of working software, the business can use past performance as an indication of how reliable the scope estimates are likely to be.

Re: Commitment versus Estimation by Bill Gaiennie

I tend to discourage my teams from habitually using the term "estimate" in place of commitment. Asking the team to make a commitment, although a simple change in terminology, really makes a large change in what they attempt to deliver. It is similar to the difference between have a vague idea of where we would like to end (a poorly defined goal) and one that is very clearly stated as the destination we must arrive at.

Will we always make good on our commitments? No, but then this is an opportunity for discussion during the retrospective. Commitments imply ownership by the developers, estimates imply detachment. We are always looking for our developers to be owners, put their bacon on the line, and really stretch to meet their commitments. We keep the value of our word on an impressive pedastal and it all starts with not simply going through the motions of making commitments, but making our commitments mean something.

Where is Ron Jeffries' message? by Stephen Molitor

The quote from Ron Jeffries above is interesting but I can't find the message and there's no link to it. I'd like to read the whole message and read the quote in context.

Steve

The Second Team Needs Some Coaching by Tim Elton

This is a great article because it combats the management practice that requires teams to always finish their Sprints on time, no matter what. That does not lead to a good place.

The second team that Mr. Cockburn referenced needs some coaching from the their ScrumMaster, and some priority from their Product Owner. They should not over-commit, just so "there is always something there waiting to get picked up". That is what the prioritized product backlog is for. If the team wants to pick up another story, then they need to go to the product backlog for it. Over-committing on purpose is bad, bad, bad.

Great Artcile but over delivery works for me! by Gary Chia

We have been under committing though not much, for a while and it has worked well for us uptil now. The team is happy, the customer is happy, the morale is high and we get enough bandwidth to prototype new approaches and work on technical debt in each sprint. Win Win.

Re: The Second Team Needs Some Coaching by Andy Skipper

Absolutely agree - the product backlog should be in good enough shape and ready to be picked from if and when the team complete what they have committed to. There should never be pressure on them to over-commit to ensure they're never short of work. This can only lead to low morale, and rising suspicion that the team can not achieve what it commits to.

For me, this really highlights the importance of the Product Owner's role in ensuring the product backlog is constantly available in priotised form

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT