What should you include in your definition of workflow in Kanban?

Why understanding the definition of workflow is important

In my opinion, the section on the definition of workflow in the Kanban Guide is probably the most important section. If you don’t understand your definition of workflow, many other things don’t work that well in the Kanban Guide as a result. If you don’t get that part, it’ll be difficult to really make progress.

What is meant by “defining your workflow”?

In the Kanban Guide, we talk about having a definition of workflow.

For a start, you need to define the kind of work items that might flow through that system. Some people use stories, for example, features, experiments, etc. → what kind of items might be going through?

You don’t need to have work item types per se. In the Kanban Guide, they’re optional. In non-software, they are more useful in reducing antibodies from people.

People tend to say, well, some things take longer than others, and it’s often a debate not worth having in the early stages because there is actually some merit in non-software where some different work item types do take different lengths of time.

But putting it very simply → you need to define what kind of work goes through the system.

Are your work items delivering value?

So as soon as we deliver it, we can confirm whether it did deliver value or not, but we have the potential to release value, whether that’s customer value, end-user value, market value, organizational value, societal value, maybe a reduction of risk or it could be learning.

What should you have in the “definition of workflow”?

• 1x “STARTED” point; and
• 1x “FINISHED” point.

There’s no limit really to how many “STARTED” points and how many “FINISHED” points you can have. Some “STARTED” points can overlap, and some “FINISHED” points can overlap.

You can even have a “STARTED” point at the start of a column and a “FINISHED” point at the end of a column. That is acceptable.

BUT whatever you have as your “STARTED” point and your “FINISHED” point, you will have four measures to go along with that as well.

So there’ll be:

• work in progress → what are the items that are in between the “STARTED” point and the “FINISHED” point?;
• throughput → how many work items are passing the “FINISHED” point per time period;
• work item age → how old are the items? How much time has elapsed since the items passed the “STARTED” point, and they have not yet hit the “FINISHED” point?; and
• cycle time → how long does the work item take to get from the “STARTED” point to the “FINISHED” point.

For each “STARTED” point to “FINISHED” point that you have, the four metrics will apply for EACH of those ranges.

So if you’ve got a “STARTED” point here, a “FINISHED” point there, another “STARTED” point here, “FINISHED” point there = The four measures will apply to each.

On the definition of workflow, you also need to show the steps through which the work needs to go through for value to be delivered. So from the “STARTED” point to the “FINISHED” point, are there steps that the work needs to go through? The simplest definition of workflow might have a “STARTED” point with one column and then a “FINISHED” point, and the work just takes as long as it takes to get through that column.

There might be a column as well for where the work goes past where it is actually delivered, and we call that throughput.

Throughput = would be the measure of how many items get past the “FINISHED” point in a particular period of time, be it a day, a week, sprint or etc.

Why do you need explicit policies in your definition of workflow?

The Kanban Guide isn’t explicit about this, but you might have, for example:

• A “Start/Replenishment policy” → how do you decide when items come in past the “STARTED” point;
• A “Prioritization policy” → if you were to start, which item would you start?
• A “Pull or Move policy” → for all the items that are in progress, if someone has capacity, which item will they work on next? It’s not always necessarily the item that you were just working on.
• A policy that says it’s based on, for example, relative item age → or you might say, we will focus on blocked items first and aging, and then we’re going to look at some other considerations.
• A policy for “blocked items” → what do you do when items are blocked? How is work in progress affected when items are blocked? Do we include blocked items in our work-in-progress (WIP) limits, or do we have some exceptions where, for example, an item has been blocked for 60 days and we made all the phone calls, sent all the emails, shook the tree, nothing’s happening and we are thinking of canceling the item. Perhaps maybe we need to put traffic on around this. We do want to exclude this item from our WIP so we can take in another item. Your “blocked policy” could be explicit about this situation.
• “Exit criteria or entry criteria per column” on your definition of workflow → this makes it really clear to the Kanban system members when an item is supposed to move, for example, from one column to the next one, how do we know that it can legally do that?

Sometimes, Kanban system members ask me:

— “Is it okay for this item to move from that column to that column?”

— I say, “What does your policy say?”

— “It actually says we need to do X, Y, and Z”.

— I reply, “Well, have you done X, Y, and Z?”

— They say “no”.

— I say, “It has to stay in the column unless your policy is wrong, of course, you can update your policies periodically. You can do it at any time, in fact.”

BUT we tend to reserve changes of explicit policies for retrospectives. These are informal sessions where we consider how we can work better as Kanban system members.

• Consider how WIP will be controlled between the “STARTED” point and the “FINISHED” point → by which means are we going to ensure that work in progress doesn’t exceed a certain amount? You might have, for example, work-in-progress limits over certain columns, on certain swim lanes (if you use swim lanes), on the active columns, for example, between the “STARTED” point and the “FINISHED” point. You can control work in progress in various ways, but the team needs to be explicit about that.
• There needs to be a service level expectation (SLE) → which is essentially an aspiration for how long items would take to get from the “STARTED” point to the “FINISHED” point. It’s not a service level agreement; it’s just that if we take an unstarted item and think about starting it, based on probabilities, what’s the likelihood based on previous cycle times? How long is that item likely to take?

We can either use:

1. an aspiration;
2. we can base it on a guess; or
3. we can use it based on historical data.

My preference is to do it based on historical data so that we are using data to inform our decision-making.

The importance of Rightsizing

Kanban guide doesn’t mandate that, but it would probably be recommended to look at the item and say, “does this feel like it fits within SLE?” If it doesn’t fit within our SLE, then maybe we need to break it down.

Can you have more than one definition of workflow?

In some cases, that’s really recommended. You might have different types of work going through the system. You might have different customers, etc. There might be some reason why swim lanes wouldn’t be enough to segregate the work, where you actually might need different, almost like different Kanban designs → so you can actually have more than one definition of workflow on a Kanban board.

You might have operational work, you might have investment work going through the board, and it might make sense that there are different columns, for example, for those different definitions of workflow. It might feel a bit too artificial having all that work going through the same definition workflow because, actually the work doesn’t quite fit that workflow.

There are other ways, of course. For example, if you had a whiteboard, you’d put crosses through the columns or the boxes, the cells where they don’t apply for this particular type of work. But on electronic boards, we tend not to have that flexibility, we tend to have an extra definition of workflow for different situations on the same Kanban board.

Another example of that would be flight levels → you might have a:

• operational boards → for individual teams on a value stream;
• coordination board → going across a value stream; and
• strategy board → for new investments coming in informed by what’s already in progress at the coordination level.

Concluding Remarks

There are lots of reasons why you might have more than one definition of workflow on the Kanban board, and it’s completely legal to do that. I would say that sometimes it is expected.

Thank you.