Should delayed items be considered WIP and what impact do they have on your delivery ecosystem?

Here at Flomatika we have a concept we refer to as Delayed Items. This designates work that has started but for whatever reason has been paused and moved back to a [Proposed State] (e.g. Backlog or To Do). Technically these work items have been ‘started’ and are considered Work in Process (WIP). Therefore, the clock has started and is accumulating WIP Age. 

One question that arises: “Should these Delayed Items appear in your WIP analysis?” You’ve consciously moved these items out of the [In Progress State] back to the [Proposed State], so do you want to see these items in your day-to-day as a reminder that these items are still accumulating WIP age? Or are they clouding your daily view and making it harder to make day-to-day decisions?

To dive further, we may need to cover a few concepts first:

Key Workflow Events

In Flomatika, we have three key workflow events that are defined for each of your workflows. These are used for a number of our calculations. Key Workflow Events can differ from Work Item Type to Work Item Type, or across different Workflow Schemes. We therefore allow these to be configured separately to ensure Flomatika accommodates to your own context. These are:

• Arrival Point: When the work enters into your system as a possible option for the team to work on. It can be ‘Backlog’ or perhaps a specific step in your workflow (e.g. ‘Selected for Development’).
• Commitment Point: The workflow step where the work actually commences or the point where the team has made a commitment that the work will be completed. 
• Departure Point: The workflow step where the work is considered ‘Completed’ or ‘Done’.
  

‍

Examples of [Proposed State] might be Backlog or Pool of Options.

Examples of [In Progress State] might be Development, Peer Review or even Waiting.

Examples of [Done State] might be Released, Completed or even Rejected.

WIP Age

WIP Age is how long a work item has been classified as a Work In Process. Specifically, it’s passed the Commitment Point and therefore has a commitment date recorded against it. WIP Age is calculated as how many days have accumulated after this date.

Lead Time

A Work Item does not have a ‘Lead Time’ until it has hit the Departure point, upon which a Departure date is recorded against the item. Lead Time is calculated as the number of elapsed days between the Departure Date and the Commitment Date, inclusive. That is, you include the Departure Date as part of the count. The lowest Lead Time you can achieve is one day, even if you started and completed the work item on the same day.

Delayed Items

Why is WIP Age still being accumulated when we have moved the item back to a workflow step before the commitment point? The reason is that the team has actually started the work (or have made a commitment to complete that work item). Therefore the timer has started and the work item is accumulating WIP Age. 

One of the constraints on any design around WIP Age is to prevent teams from corrupting their Lead Time Data by “resetting” the timer by moving items from an [In Progress State] back to [Proposed State], either inadvertently while grooming their boards and backlogs, or maybe even through gamification (essentially being able to directly influence the reported Lead Time). 

We have intentionally allowed one exception to this to accommodate planning, if perhaps an item was moved incorrectly and immediately moved back. We therefore will exclude items that have moved into and out of an [In Progress State] on the same day.

Any item that has a Commitment Date recorded but currently resides in a [Proposed State] is considered as a Delayed Item. These items that have started, but have been moved back a workflow step before the Commitment Point and is once again considered as an ‘Option’ for the team. 

‍

Should Delayed Items be considered in WIP or Inventory?

Now that we’ve covered some of the concepts, the question is: “Should we be displaying Delayed Items as WIP?”

These items have a commitment date, so by definition should be shown along with all the other WIP items. These items are ageing, a customer expectation has been set, and they are now waiting for the work item to be delivered. Teams should be conscious of these Delayed Items and they should have a plan in place on how they are going to manage these. 

They do, however, get mixed in the WIP perspective along with the actively worked on items. This can add additional cognitive load to the teams having to remember which WIP items are Delayed Items and which are not. These Delayed Items typically are not part of the day-to-day decision making and prioritisation process. The team is likely aware of the reasons the items have been delayed and possibly have little control of these in the short-term. Seeing them in WIP just adds to the “clutter”.

Despite having a commitment date recorded, Delayed Items do currently reside in the [Proposed State]. So, it also makes sense to have them appear in the Upcoming Work/Inventory perspective instead. The disadvantage to this approach is that they are hidden away out of sight from the WIP perspective. If it’s not consistently visible, you’re likely to forget about them. Out of sight, out of mind. So there is a level of caution in taking this approach. 

‍

So how should you handle delayed items?

You’ll need to introduce a mechanism in your ways of working to include Delayed Items analysis into your existing review sessions (Retrospectives, Service Delivery Review, etc). Ask why they had become delayed. Is this a regular form of waste introduced? Is there something we can do to prevent future occurrences? How is the WIP Aging impacting our customer expectations?

In terms of if Delayed Items should appear in WIP or Inventory? It’s likely one of these approaches is more relevant to you within your own context. Perhaps you’re able to keep your WIP low and only have a very small number of delayed items, in which case seeing them day-to-day works better as a reminder to action rather than a distraction. 

Alternatively in your environment, you may have very limited control over which items become delayed, and they stay in that state for a long time becoming more of a distraction in the day-to-day decision making. In such a case, Delayed Items might be better suited to being viewed as Inventory as it leans towards strategic decision making rather than a more tactical one.

Flomatika empowers you to select the approach that is more applicable in your context. This can be switched via a toggle in the Filter Panel to show Delayed Items in WIP, or Inventory:

Regardless of which approach you take, be sure to include some sort of Delayed Items analysis into your existing cadence.

In the meantime, we’re looking at other ways to assist with analysis of Delayed Items. Here’s an early preview of something we’re working on along this vein.

For more information on the platform, you can schedule a demo with us through this link or you can subscribe to our newsletter to stay updated with the latest features we develop for the platform.