Over-Commitment Versus Over-Delivery
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.
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.
Commitment versus Estimation
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
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?
The Second Team Needs Some Coaching
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!
Re: The Second Team Needs Some Coaching
For me, this really highlights the importance of the Product Owner's role in ensuring the product backlog is constantly available in priotised form