The main sections of the change canvas are meaningless unless all stakeholders involved in the change can successfully make the commitments required to achieve potential benefits. These two sections can be thought of as being balanced with each other, and supporting the remaining sections within the change canvas.

Commitments

Use the commitment portion of the canvas to track what is required from all involved to make a change successful.

Change recipients and change agents are required to meet the commitments specified within the canvas in order to realize the benefits that will be achieved from getting to the target state.

Interestingly the commitment section of the canvas is often the most important one to change recipients. One of the most focal point of resistance to any agile or Lean Change initiative is that change recipients are too busy to take the time to think about improving the way they work. The best way to tackle this concern is to hit it head-on, defining what commitments change recipients can actually make, and then tweaking the rest of the canvas to take into account the available resources.

Commitments come in the way of locating spaces for agile teams or dedicated meeting rooms at specific times to run workshops and classrooms.

commitment can also come in the form of hardware, software and other tools that change recipients may not currently have access to.

Often the most contentious form of commitment comes in the form of time required to learn, practice and accelerate in new methods.

At a minimum is critical to capture an estimate of how much time is required for each change recipients of a particular change. have noticed the change recipients are more willing to give more of their time if this commitment can be tied to specific benefits that will make their lives easier.

On occasion we have found it necessary to provide a more elaborate picture of how particular change will affect people's schedules. The calendar type view can be used to show when all meetings are taking place, how long they will be, and who is required to attend. While this might seem overkill, we have found that this type of illustration helps reduce churn when negotiating a change model with change recipients.

Continuing our previous example, we've illustrated our initial assessment around the time commitment required to help this team gain proficiency in agile modeling and requirements.

Benefits

A successful change initiative will result in benefits received by change recipients

Use the benefits section of the canvas to articulate what benefits change recipients will receive as a result of committing to the actions required to make the team successful.

Benefits listed in the canvas can be both qualitative, as well as quantitative.

Types of benefits that could be listed on the change canvas include improved customer perception. Listing this benefit takes some courage on about half of change recipients, they are signing up to definitively improve the way their customers feel about the way they work. We think this is an ideal outcome for trying to pilot new methods, it makes a bold statement that no success is meaningful unless the customer experience is improvement.
Borrowing another page from the mean startup method and metric known as net promoter score could be used to track both current and expected customer perception.

Team performance is also something we have commonly used on our campuses. Change recipients who are using more classic agile methods such as from scrum and extreme programming can try to quantify benefits in terms of velocity using burn down charts, and other metrics such as how often teams are able to meet their commitments.
Change recipients using more lean inspired methods such as Kanban can try to quantify performance improvements in terms of throughput and leadtime, leveraging cumulative flow and fiscal process control charts, as well as other metrics such as how often a team is able to meet its service delivery performance promises.

Trying to articulate the exact impact on performance they change initiative will have is a highly subjective art at best. We have seen teams using Kanban report drastically different throughput performance improvement outcomes ranging from 30% to a whopping 200%!

Our team has also seen teams improve their performance up to six times over the lifecycle of a project in A large part because they had the chance to gel, and collaborate effectively.

our team has also noticed that the unit of measure, whether it be user stories or features, tends to change in size and effort once it's been measured. Teams that measure their performance often start trying to shrink their user stories to a small they can be while still delivering business value, this alone has a dramatic impact on performance.
What this means is that implementing a change on anything but a very stable team any quantifiable perform improved you suggest will be a guess.

We still think that specifying performance improvements is a good thing to Do for many change canvases, especially when trying to adopt a method on the team. Without this business valued promise of improvement, it can be hard to get the buy-in necessary to make any type of reasonable change to the way people are working.
We think the best number to specify is on the aggressive side of conservative. Specifying a number close to 80% improvement in either defect density, leadtime, or throughput/velocity is achievable for most change recipients that we have encountered, and is also large enough of a number to generate interest in the change itself.

Benefits can also be described in terms of improved capability of the change recipients. While this can be expressed in numbers, this is really a qualitative benefit. One way to do this is to simply express the number of change recipients who have achieved capability in a certain skill.

Capability could be expressed in terms of a graduated ladder, or if desired more complex capability model could be designed to support the change. In this case, capability benefits could be described as the number of folks reaching a certain level within the capability model.

Looking at our previous example, we can see our assumptions around benefits both from a performance as well as capability perspective as a result of executing this change.