What is a commitment point anyway?

In some way, commitment is part of almost all project work. The term used to be part of the planning ceremony/event in Scrum (actually it has been for quite a while since one could find the snippet ‘commit’ outside the ‘values’ section of the scrum guide. See the history of the Scrum Guide, section “Changes between 2010 and 2011” for Details) and the term ‘committed work’ comes up over and over again when talking about flow based systems. (Those flow-based development processes often come together with application of the Kanban Method)

Commitment in Scrum

Even though the notion of committing (and thus promising) to the result of the planning meeting has been thrown out of the window some years ago, the notion is still very much alive out there in the fields.
The general idea here is that the team commits to a Sprint Goal often backed by a bunch of backlog items, and the ‘commitment’ here is the (not always realistic) idea that the team will deliver and reach the sprint goal by the end of the sprint. Which is actually consistent with what Ken Schwaber wrote about Scrum in the early years – you might remember the ill-suited story of the chicken and the pigs that also vanished from the Scrum Guide between 2010 and 2011.

The main takeaway here is that with this kind of planning commitment relates to the result and says nothing about the way the work is performed.

Commitment-points in Kanban-Systems

In the World of Kanban the notion of commitment is different since Kanban is not a software development process but a set of principles and practices for process improvement and organizing work.

Many of the processes which teams create with Kanban tend to be flow based and thus ‘commitment’ most often refers to a point in the workflow where the ‘unit of work’ is committed into the system. From here on its flow is governed by the process policies (working agreements) and WIP-Limits.

A while ago I wrote about a problem with unbounded –or uncontrolled– columns for requirements and how it can be addressed by making only promises about things that are under voluntary control. This is actually the introduction of commitment points.

The change from red to green in the last picture of that article illustrates the commitment point for the development workflow. From here on the work is committed into the system.

Effective difference

Commitment in Kanban controlled flow processes is an attribute of the system, not something that Managers can hold against the team. It is not a promise for some point in the future (the System under development will be able to...) but it is the fact that this item is now in the system and will be worked on according to the explicit policies the team agreed upon.

And that is a promise that –most of the time– can be kept. Together with other attributes of Kanban-Enabled Systems this makes for much more reliable forecasts based on systemic behavior and measured data.

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))