{"id":3360,"date":"2021-05-27T10:40:54","date_gmt":"2021-05-27T09:40:54","guid":{"rendered":"https:\/\/getnave.com\/blog\/?p=3360"},"modified":"2023-03-16T21:41:28","modified_gmt":"2023-03-16T19:41:28","slug":"abandoned-work","status":"publish","type":"post","link":"https:\/\/getnave.com\/blog\/abandoned-work\/","title":{"rendered":"How to Handle Abandoned Work Items to Preserve the Stability of Your Delivery System"},"content":{"rendered":"
<\/div>\n

Discarded work has a massive impact on the predictability of your system and your overall performance. Even though this is a hugely neglected topic, it actually has great potential to introduce opportunities for improvement in your working practices.\u00a0<\/em><\/p>\n

I\u2019ve never been skydiving and I probably never will. In my honest opinion, you must be genuinely insane to take a parachute backpack, hop onto an airplane, fly up to 10,000 feet and jump out into the sky.<\/p>\n

Once you jump out of that airplane (apart from proving that you\u2019re out of your mind), something very important happens. You commit to falling back down to the ground. Up until the moment you leave that plane, you had every chance to give up. Jumping into the sky is the actual second that you commit to getting back down to the earth.<\/p>\n

When you start a new task, you commit to delivering it.<\/strong> Once your work item gets pulled into your workflow, you commit to meeting your customer\u2019s expectations and finishing the work. It\u2019s a promise that should always come with a high level of confidence that you are going to keep it.\u00a0<\/p>\n

Let me ask you something – would you jump out into the sky if you didn\u2019t know whether or not you would land back onto the ground? Probably not.<\/p>\n

Nevertheless, very often, work items get aborted in the middle of the delivery workflow. And here is the thing – the further your work has moved through your value stream, the higher the amount of time and effort you\u2019ve already spent on it.\u00a0<\/p>\n

If this is a behavior that you observe, it is tremendously important to acknowledge that fact and take action to prevent it from happening again in the future.<\/p>\n

The Impact of Dropping Out Cards from Your Board on Your Predictability<\/h2>\n

Ok, let\u2019s be realistic. It is reasonable to cancel work items in the middle of your delivery workflow if you decide that they no longer provide customer value. There is no point in investing more time and effort into finishing something that no one will benefit from. That just doesn\u2019t make sense.<\/p>\n

In terms of predictability, there is a good way and a bad way to cancel a work item.<\/p>\n

The Bad Approach to Discarding Work In Progress<\/h3>\n

The bad approach to handling this situation is to pull the card out from the board or delete it altogether. There are two reasons that prove this point.<\/p>\n

    \n
  1. By removing a task in progress, you break Little\u2019s Law assumptions.<\/strong> Little\u2019s Law<\/a> defines stable systems. One of Little\u2019s Law assumptions states that \u201call work that enters the system must flow through the completion and exit of the system\u201d. By deleting a card in the middle of the process, that assumption won\u2019t hold anymore. Therefore, you will affect the stability of your system. The less stable it is, the less predictable it becomes.<\/li>\n
  2. By dropping cards out from the board, you lose opportunities for improvement.<\/strong> Aborting something you have already started is a bad practice in every sense. You want to know what caused that behavior and how often that happens. It is important to learn a lesson from it and identify opportunities for improvement in order to prevent it from happening again. By dropping out discarded items from the board, you don\u2019t solve the problem, you cover it up.<\/li>\n<\/ol>\n

    The Good Approach to Handle Abandoned Work<\/h3>\n

    In order to preserve Little\u2019s Law assumptions and enable the possibility to analyze your discarded work, it would be much better to add a \u201cDiscarded\u201d label to the ticket and move it to your \u201cDone\u201d column<\/strong>.\u00a0You can then collect all the discarded items and investigate what has caused that behavior.<\/p>\n

    You should strive to meet the Little\u2019s Law assumptions to maintain a stable system because stable systems translate to predictable systems.\u00a0<\/p>\n