Kanban Boards Show Team Flow and Bottlenecks
Kanban boards are each unique to their teams. That’s because each team has its own unique flow.
The following kanban board has WIP limits on all major columns, including the Ready column. The WIP limits exist to make sure the team sees its flow and possible bottlenecks.
The Ready column has a WIP limit because the product owner can change what’s in the Ready column. This particular team has a step called “Discuss Story” in its flow. That column also has a WIP limit so the team doesn’t get too far ahead of itself.
Notice that this team has a WIP limit on the number of stories in Dev-Done. You can think of the Dev-Done column as a buffer for the System Test column.
Each of the columns with WIP limits is full, which means this board is full. If the team respects its WIP limits, the team can’t start a new story, nor can it take a story into Develop and Unit Test. This team has to move a story from System Test to Done before anything else on this board can move.
When the team has a full board, the members look at the board from right to left, to see what is closest to done. The team has a responsibility to move whatever is in System Test to Done before pulling any more work. (See Walk the Board, for more specifics.)
One team discovered that its board looked like the (overloaded) Scrum board shown in the following figure.
The team had started with a Scrum board. They had many items in the “In Progress” column. The developers noticed they were always “ahead” of the testers. They decided to create the kanban board to see where the problems were. With a kanban board, the team was able to see the problem. The testers were behind on creating test automation, and had to test too much manually.
The developers and testers paired on the work in System Test until the team created sufficient test automation for the team. Because they saw the bottlenecks, they could discuss the problems and fix them as a team.
Once they cleared the System Test bottleneck, they could move to the next leftmost column and see why they had bottlenecks there. Once they cleared their bottlenecks, they create WIP limits to manage where they had work in progress.
The short answer is yes. A resounding yes.
When people limit their work in progress, they make it possible to finish work. When people finish work, they feel a sense of accomplishment. That sense of accomplishment allows them to finish more work. (See The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work [AK11] for more specifics.)
When a team respects its WIP limits, it commits itself to addressing only the work it can. The members will work as a team to finish the work on its board. Creating and respecting WIP limits is a form of team commitment and agreement on how the team will work.
One of the reasons I suggest you Start with a Paper Board, is that paper has natural WIP limits. If you can’t fit any more paper on the board, the team has its WIP limits.
For example, if your team has interruptions from support, you might need an Urgent queue on your board. The board in the image has one urgent item. That means that, depending on the agreement with the people who put items in the Urgent queue, the team might stop working on one of the items it’s working on now and have more WIP. The additional WIP is the work the team stops plus the new work.
Every team has a different meaning for “Urgent.” Some teams use Urgent as “Stop what you’re doing right now and start this.” Some teams use Urgent as “Take this next.” If you use an Urgent queue, decide if the team can override WIP limits to take on new work. Almost any decisions your team makes are fine, as long as it makes a decision about what Urgent means and if and when the team can override its WIP limits.
If you do use an Urgent queue, consider defining response time in the working-agreements part of chartering the team. See Ask the Team to Develop Working Agreements.