Commitment is defined as the act of binding yourself to a course of action. In Scrum, commitment has a strong meaning and Scrum practitioners suggest that authentic Scrum is not possible if people are not keeping commitments. In-spite of this, forums have a lot of questions about commitments not being met. Do we understand the real meaning of commitment?
Jens Coldewey suggested that commitment in an Agile team is the commitment done by a self-organizing team to do a good job. This is a team where the team members are enthusiastic and take pride in their work. Commitment on the number of stories which would be completed or the number of story points which would be delivered is an incorrect form of commitment.
Committing to certain stories or a number of story points is like a surgeon committing to a certain time period in which the patient recovers: you commit to something that is simply out of your control. If a team does not finish as many stories as it thought it would during the planning meeting, it just means that it has responded to change.
According to Jens, commitment to anything, apart from doing a good job with passion violates the Agile Manifesto too. If a team commits to deliver a certain number of story points 'no matter what' and they happen to encounter a change then, there are only two possible options to meet the commitment. Either by putting in extra hours or reducing the quality.
Likewise, John Sonmez quoted that though commitment is an unspoken central theme of Scrum however, in reality the biggest weakness of commitments is that they cannot be followed due to one reason or the other in the real world context.
So, what is wrong with commitments? They cannot be followed. The business doesn’t want to change priorities, but a critical issue comes up. The development team wants to commit to the sprint, but the development team can’t make more code get done faster simply by wanting to. They can add more hours to the sprint, but then they are skewing the velocity. The only way the development teamcan realistically commit to the sprint is to ‘pad’, and that is a very bad word.
Another problem with commitments is the one suggested by Chris Goldsbury. Different people might understand different flavors of commitment. For some it means to complete the stories and tasks in the iteration no matter what and for others it might mean 'trying' to complete the stories and task with the underlying assumption that some of them would move to the next sprint. This subtle difference in understanding results in a huge difference of outcome.
In a similar discussion, Glenn suggested the following definition of commitment
The commitment that a team makes is to work professionally and follow the rules of Scrum. The Sprint end date is fixed. There is no commitment to content. Of course meeting the commitment means many things including getting backlog items done-done. If backlog items remain undone at the end of a Sprint then they go back on the backlog.
Rawsthorne and Shimp described their technique for 'commitment based planning'. According to them, one of the reasons for it to work is that it is not based on sizing of stories. It is rather based on realities and facts at that very moment of time, taking the current situation into account rather than doing a commitment based on story sizing done in the past.
Hence, according to many people in the Agile community, defining a commitment based on stories and story points does put some checks and balances in places for the validation of the sprint, however the real commitment is still the dependent on the passion of the people and their willingness to win.