One of the top reasons behind delaying (or even canceling) work that has already been started is the act of early commitment. When our work items move into the delivery process while we still have a little knowledge about what needs to be achieved, we directly hinder the predictability of our workflow.
To overcome that obstacle, we need to explicitly define the point at which we confirm that we are ready to initiate our work and commit to delivering it. That’s what we refer to as a commitment point.
Naturally, we tend to say “Yes” to our customers right away. We all want to come across as tolerant, kind and polite. Our aim is to keep making our clients happy, but committing early won’t help us achieve that goal.
Your customers will only be happy if they receive what they’ve requested on time and of high quality. Managing realistic expectations is crucial here. If your process is brimming with tasks, you ought to ask yourself whether your team is capable of handling new work at that point.
Starting more work rather than finishing old work leads to overburdening, less attention to detail and delayed delivery. The earlier you commit, the higher the chance of breaking that commitment.
Defining a commitment point will enable you to avoid this situation. By keeping your work optional while it is being requested, you can preserve the predictability of your delivery system, maintain the balance between demand and capacity and intentionally reserve the time to discover whether it really makes sense to invest in this work.
What is a Commitment Point in Kanban?
We should unambiguously define the point in time at which we commit to delivering our work. This is our commitment point.
A commitment point is not the point when a customer request arrives. It is the moment in which we have gathered enough knowledge about the work to say that we are confident and capable of initiating it.
We need commitment points to create alignment between everyone involved. When our work reaches and is taken through that point, essentially, we make an explicit two-way commitment.
Our business representatives have evaluated the work, they confirm that they understand the risks associated with it and that they are willing to invest in it. The work is unambiguous and well-defined and it meets all requirements of Definition of Ready.
On the other hand, by pulling the work through the commitment point, our delivery teams confirm that they have reviewed the work, they understand it and they have everything they need to start working on it. They commit to delivering that work.
The Benefits of Defining a Commitment Point
Explicit commitment points come with a handful of benefits.
First, all the work before the commitment point is considered to be optional. Some of that work can and should be discarded when you start narrowing down the funnel of your customer requests.
Your commitment point separates your upstream from your delivery process. As you shift your options closer towards your commitment point – which happens as you discover more knowledge about the work – they go through the steps of being proven and validated that they have a good business case. What’s more, they’re much more likely to be delivered in a predictable time and to a high quality.
When your work moves through the commitment point, it is no longer considered optional. It is converted into a commitment. That’s the moment when the clock starts ticking. It’s the starting point from which you measure your delivery time.
How Commitment Points Enable Reliable Service Level Agreements
Let’s analyze the following use case.
This team manages both the upstream and downstream processes on one board. Their upstream workflow has the following activities: Options, Good Options and Next Options. The delivery workflow consists of Development, Testing Queue, Testing, Under Review Queue, Under Review, Deployment Queue, Deployment and Complete steps.
Their discovery process starts with adding all requests to the Options column. Then, if an option fits within their strategy, it moves to the Good options column. In this step, they evaluate the work, create risk profiles, acceptance criteria and outline the definition of done. Essentially, they include all the information needed to unambiguously define the scope of the work.
Then, the item moves to Next Options. This is a queue state; it denotes that the work is ready to be pulled into the delivery workflow.
This team doesn’t hold an explicit Replenishment meeting, in which a certain set of items are prepared for development through a certain cadence. The commitment is asynchronous; they pull the items from the Next Options column once they have the capacity to start new work. Their commitment point is the moment in which the work is being pulled from Next Options to Development. That’s the exact point at which they commit to delivering the work.
Now, by having an explicit commitment point defined, this team can easily provide a reliable Service Level Agreement. Let’s look into their Cycle Time Scatterplot.
Now, what they have to do is deselect all the upstream steps from the Lists filter. Once done, they can evaluate how much time they will need to finish the work, alongside the probability that comes with that commitment.
For example, the 85th percentile points to 11 days. This means that they will finish the work in less than 11 days, and there is an 85% chance of keeping that promise. They also know that the commitment to finishing their work item in less than 15 days comes with a 95% certainty.
Furthermore, they can filter their data by class of service. This is particularly helpful if they need to make a more precise evaluation of their delivery times, based on the urgency of the work. This approach is very useful for Expedite or Fixed Delivery Date items.
If you’re striving to build a stable delivery system and achieve consistent predictable business outcomes, I’d be thrilled to welcome you to our Sustainable Predictability program.
Start with defining your commitment point and make sure that everyone involved is aligned with that concept. Make it clear that moving work items through that point is an act of committing to delivering these items.
It is crucial that you understand that in Kanban, commitment is not just a promise to a point in the future. Instead, it is an explicit confirmation that a work item will be executed following the process policies and delivered to the customer within a given Service Level Agreement.
Using commitment points gives us transparency, clarity and alignment. They make our process more explicit and our workflow much more predictable. All in all, it makes it far easier for us to create fit-for-purpose customer services.
