The Kanban Pocket Guide: Chapter 3 - Actively Managing Items in a Workflow

I once worked with a team that had designed a Kanban board which had a global Work In Progress limit of 9.  They had also added an expedite lane on their board (a big no-no as anyone who has followed my work knows) but at least had set a WIP Limit of 1 for that expedite lane.  I walked up to the board one morning before our daily standup and saw that there were 32 items in the expedite lane.  This is a classic example of not actively managing items in a workflow.

What's the point of defining a workflow, setting WIP limits, agreeing pull policies, etc. if you are just going to ignore them?  The second practice of Kanban, "Actively Manage Items In a Workflow", is where the flow rubber meets the praxis road.  Kanban is about flow and flow is about movement and movement doesn't happen on its own.  As Deming says, a system needs management ^1^, and systems based on flow are no different.

Active management of items in a workflow can take several forms, including but not limited to the following:
* Controlling WIP
* Avoiding work items piling up in any part of the workflow
* Ensuring work items do not age unnecessarily, using the SLE as a reference
* Unblocking blocked work

As discussed in Chapter 1, your primary tool for active management of WIP is to monitor age.  That is, the only way we can know with any reasonable amount of certainty whether items are not flowing the way we expect them to is look at age.  But as we also saw in Chapter 2, the best information in the world is no good unless you do something with it.  

What follows is a deeper dive into some actions you can take when you see that items are taking too long to complete.  This is by no means an exhaustive list, but these are very good places to get started.

Pairing, Swarming, and Mobbing

Work items often reveal previously unknown complexity as they move through the workflow. This complexity can cause them to age more than other items. An item that has aged to an extent that it stands out in context of the team's flow, deserves some special attention. This might come in the form of having multiple team members jump in to help on this item (beware Brooks's law). This will often mean lowering WIP to help the aging item make progress. Folks finishing the next item should be asked to help out with the aging work item instead of picking up new ones. The act of lowering WIP to below the number of team members is known by multiple names - Pairing, Swarming and Mobbing to name a few. For ease of reference, we will refer to all these as Ensemble work.

There are three major ways in which ensemble work can help control age.

* Completing downstream tasks earlier - As an item ages in an earlier stage, we can enable faster flow through later stages. We can perform steps in the later stages earlier so that the task does not continue to age unnecessarily once it is past the current stage.
* Dividing work item tasks amongst team members - If the work item itself cannot be broken down into deliverable chunks, it is possible to identify sub-tasks of the item. Different team members can take on the varying subtasks in parallel to help the item move forward.
* Removing Sticking Points - Often getting fresh perspectives on a problem a single team member has been facing helps in coming up with creative solutions. Whether these are just a result of "rubber ducking" or cross-functional pairing to get new perspectives, they help an aging item make progress.

Unblocking Blocked Work

By definition, any work that is blocked or on-hold is not flowing. These work items age, usually due to internal or external dependencies. If the cause is an internal dependency, we need to examine our process policies and look for improvement. If the cause is external, we need to figure out how to reduce the likelihood of this external dependency for future items or reduce the impact of this dependency on age. In other words, how do we get closer to eliminating the dependency or making the resolution time insignificant. Bringing external expertise in house, improving partner/vendor relationships or completely removing the dependency are all options we can exercise here. Whether the dependency is internal or external, we need to establish some policies around how we treat blocked work. There are at least three levels of blocked that need to be established -

* When to mark an item as blocked - How much time needs to pass before we mark an item whose progress is stopped as blocked? Is this in the order of hours, days or weeks?
* Blocked Items and WIP Limits - How long should a blocked item count towards our WIP limits and stop us from picking up other work? Does including it in WIP increase our focus on resolving it?
* Removing Blocked Items from the system - At what point do we say that the item is going to be blocked for so long that it might not be relevant to track it? Should we cancel the item or move it back to the backlog?

Right Sizing Redux

Read Don Reinertsen's "Principles of Product Development Flow" book and you will quickly realize that one of the biggest detriments to flow is working on items that are too big. In flow terms, that means controlling batch size. We saw earlier that usually when an item is stuck in your process it is because it is too big--it hasn't been right sized.

Right sizing is the art of enabling work to flow in small batches of value at every level. This means breaking things down into small, manageable chunks.

For sizing, all you need to do before you pull an item into your process is have a quick conversation about whether you can—based on what you know right now—get the item done in 12 days or less. If the answer is yes, then the conversation is over and you pull the item in and start working on it. If the answer is no, then you talk about how you can redefine the work item such that it is of the right size. Maybe you need to break it up. Maybe you need to tweak the acceptance criteria (more on breaking items up in the next section). Whatever the case, take the action you need beforehand and only pull the item in once you are 85% confident you can finish it in 12 days or less.

Prateek Singh communicated this guidance on right sizing when working with one of his teams:

"We have a general idea of how large work items at every level have been in the past. We can use this to ‘size’ upcoming items. Currently we have a very good idea of sizing at the story level due to the data available. We are also going to lay out guidelines at the Epic level based on historical understanding of flow.

"In the Cycle Time scatterplot for our team, we noticed that 85% of the stories that we work on get done in 11 days or less. This is a guide for right sizing. Whenever the team picks up the next story, they should be able to ask themselves the question, 'is this the smallest bit of value and can it get done in 11 days or less?' If the answer to those questions is yes, great, no more estimation needed, start work on it. If the answer is no, let us try to break this story down. This is the essence of right sizing. Each team will figure out their right-size stories from their own data.

"For Epics - since we do not have great data, but a decent general idea in this regard, we are issuing some guidance. Epics should be 10 stories or less, 90% of the time. 10 is a soft number, it is something to aim for. The reality is that there will be Epics that will become 11/12 stories big. 90% of our Epics should be 10 stories or less.

This does not mean that we try to make all Epics close to 10 stories. The 'or less' part is important. If an Epic can be delivered to a customer in 3 stories, great, let us leave it that way. 10 is a soft upper bound, not a target."

This is all well and good, you may wonder, but how do we go about breaking items down once we recognized they haven't been right sized? I'm glad you asked.

Breaking Down Work Items

When you discover that an item is too large for your process, your first hypothesis should be that this large work item is probably composed of smaller, individually deliverable bits of value. Packaging multiple items into a single work item can negate many of the benefits that limiting Work in Progress provides. For example, if we are operating with a WIP limit of 1, but that one item could potentially have been 5 separate items, our WIP is actually five times larger than what is visible. WIP often hides in work items. In order to expose our actual WIP, we should be breaking down work into individual ‘feedback-able’ pieces early and often.

Let's now walk through some simple strategies that can be used to break down work. It is a list that I and others have successfully used in the past to break work down. These strategies are effective at every level of work - stories, features or initiatives. Multiple of these strategies can be applied to the same work item as well. The end goal is to create smaller units of work that can help us get faster feedback from our customers.

Acceptance Criteria

The practice of adding user Acceptance Criteria (AC) helps us understand how a customer would expect to benefit from the work item. If the team works on initiatives that break down into features which are in turn composed of stories, each of those levels should have an acceptance criteria. At every level, we should be able to break work down by getting closer and closer to a 1:1 ratio of acceptance criteria and the work item. This does not mean that every story, feature or initiative should have only one acceptance criteria. Instead, we should look for each work item to have the minimum number of ACs that help us get feedback.

For example, consider the following work item.

As a reviewer I want to see the relevant sections of a submitted paper broken out so that I can easily assess them
* AC 1 - Reviewers should be able to see the title of the paper separate from the body
* AC 2 - Reviewers should be able to see the word count of the description
* AC 3 - Reviewers can grade each section separately
* AC 4 - Reviewers are able to view the main hypothesis in a separate section
* AC 5 - Reviewers can optionally separate out experimentation details to be assessed separately

In this case each of these ACs can be a separate work item. They can all independently be delivered to customers (internal or external) for us to get feedback. Each of these ACs starts solving a customer problem and delivers value without being held up for the others to finish.

Conjunctions and Connectors

Very often WIP hides in the titles of work items. Any time we see conjunctions, particularly ands and ors, in a work item title, it is an indication that the item can be broken down. Sometimes these are replaced by commas, dashes and slashes as well. These conjunctions and connectors are usually trying to lump multiple actions or actors into a single work item. Separating these can help us deliver on individual actions earlier.
For example the work item shown below can be broken into multiple items

* Patrons should be able to give restaurants overall, food quality, service and ambiance ratings

This work item can easily become four different work items as listed below. The delivery of the overall rating might be a part of the minimal viable product, while others can be later enhancements.

* Patrons should be able to give restaurants an overall rating
* Patrons should be able to give restaurants a food quality rating
* Patrons should be able to give restaurants a service rating
* Patrons should be able to give restaurants an ambiance rating

Generic Terms or Plurals

Generic terms are often used in work item titles to represent what should otherwise be multiple requirements. Getting a greater degree of specificity can help tease out the smaller work items that are hiding within the large one. Greater specificity also leads to better test plans, with fewer missing test cases. In fact, talking about how we would test an item is often a great way to move from generic to specific work items.

* The system should flag items with appropriate colours based on severity.

In the above item the generic terms ‘colours’ and ‘severity’ can be made more specific to create smaller work items which can then be prioritized. These items can be as follows -

* The system should flag events with greater than 90% impact as red.
* The system should flag events with between 50% and 90% impact as yellow.
* The system should flag events with less than 50% impact as green.

Optimize Now vs Later

This strategy focuses on a minimal viable increment approach at every level. What is the simplest, least optimized solution that we can deliver to start getting feedback from internal or external customers? The customers might want a lot more than the first deliverable, but we would get increasingly more aligned and deliver value with each increment. The example below shows how this can be done.

* Provide customers the ability to order pizzas listed in our menu online.

The above work item can be broken down into a few smaller items.

* Provide customers a button to order margherita pizza online.
* Provide customers the ability to change the size of pizza ordered.
* Provide customers the ability to pay for the pizza online.
* Provide customers the ability to select from a list of pizzas online.
* Allow customers to add/remove toppings from pizza orders.
* Allow customers to build their own pizza by adding toppings to a basic cheese pizza.

There are multiple such strategies that can be used to break work down. These techniques can be used in conjunction with each other to enable faster and more frequent delivery of value. They should be used at every level of work definition.
The following diagram is a cheat sheet that Becky McKneeley put together while working at Ultimate Software. It represents an excellent getting started guide for breaking down work items.

Conclusion

The world is going to conspire against you to make your process as unpredictable as possible.  Diligence is required to spot when items are taking too long, but more importantly diligence is required for prompt action.  The world is indeed a nasty place out there and you should thank your favourite deity that you have Kanban on your side. 

Wouldn't it be nice if aging alone allowed us to see all of our process ills?  It does not.  Unfortunately, aging itself is dependent on how we have defined our workflow, so it is the nuance of a defined workflow that we will discuss next.

Endnotes

1. W. Edwards Deming, "Out of the Crisis" (The MIT Press, 2000)

Remember you can always download a PDF of The Kanban Pocket Guide here: https://prokanban.org/kpg/