Over-Commitment Versus Over-Delivery

Posted by Vikas Hazrati on Jan 13, 2009

Sections

Process & Practices

Topics

Self-organizing Team ,

Teamwork ,

Agile in the Enterprise ,

Scrum ,

Agile

Share |

RELATED Research

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.

RelatedVendorContent

Agile Maturity Model Applied to Building and Releasing Software

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   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.

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   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

   Reply

4. Back to top

   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.

   Reply

5. Back to top

   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.

   Reply

6. Back to top

   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

   Reply