Controlling Work In Progress (WIP) is good but...

Controlling Work In Progress (WIP) is good but...

 m

... there is more we can do to help optimise the flow of value through our workflow and have a predictable system.

The Visualisation below shows:

1. A Kanban board with a simple workflow - To Do, Doing and Done.

The Cycle time measure is the elapsed time of a work item between a start point and a finish point.

For this simple board, we are capturing the cycle time for each work item from the point when a work item is moved from:

  • To Do to Doing (start)
  • Doing to Done (finish)

In this example, the maximum WIP constraint is 2 work items in Doing at any time. This is never exceeded.

Workflow Aging and Cycle Time

2. The Work item aging measure is the elapsed time from when a work item was started but not yet finished.

The age of a work item here is visually represented by its changing colour. The more it ages, the darker it gets.

3. A cycle time scatterplot chart below the Kanban board

When an aging work item is completed, it is no longer aging and is replaced with the cycle time measure as we now know how long it took to finish.

Each corresponding dot on the cycle time scattergraph chart shows historical data for:

  • The date when a work item was finished (x axis)
  • Cycle time for each work item (y axis)

What can be seen half way through the period of observation is a work item remaining in Doing which is aging more than it naturally ‘should’ before it eventually is moved to Done. Some special cause outside of the norm happened to this work item. This occurrence is captured and can be easily identified in the cycle time scattergraph as the grey dot with the high cycle time.

When special cause variation occurs, it makes our system less predictable as the process is not in statistical control. If our recent historic data is a good representation of how we will do in the future, we have more confidence in forecasting when work items may be done when we have a predictable system (i.e. work completed within common cause variation range).

The green banding in the cycle time scatterplot chart below represents the cycle time range work is usually completed within given the natural (common cause) variation in our process. Other practices can be applied to this data to understand the behaviour of our process better to help distinguish between signal (special cause variation) and noise (common cause variation)

Cycle Time Scatterplot

This is an example with a simple workflow and low WIP. The more complicated the workflow and higher WIP, the greater the chance of work items aging unnecessarily resulting in larger cycle time variance.

Controlling WIP is a good start to managing items in a workflow but is not enough to have a stable predictable process. The Work Item Aging measure can help identify where something has stalled and be used as a signal to take action to actively manage it to unblock/resume the flow of work. This will aid in having a predictable stable system.

(My previous article shows how to implement aging colour coding in JIRA)