Ask a Kanban Trainer: Your Mindblowing Questions - Answered

October 6, 2024

The Meetup Group 10/20/2023

Ask a Kanban Trainer is an Ask Me Anything (AMA) format session with ProKanban.org trainers answering your APK, Kanban, and Flow Metrics questions. These are held monthly via our Meetup group and are an absolute blast!

Our last session was on 10/20 and featured professional Kanban trainers Ingrid Nunes, Will Seele, and Jim Sparks.

Unanswered questions

As promised, we try to get all your questions answered in these sessions. Sometimes, the great conversations that happen do not allow us to get through them all. When this does happen, we will follow up with a post to answer them. Feel free to jump into our Slack community to get answers to your burning questions without waiting for this post.

This last session left us with only one unanswered question:

If an item fails a QA Review or QA test for example (yes, it's a handover) for whatever reason - do you keep it in that column where if failed? As some devs like to move it back to 'in progress'. That messes with CT metrics and forward progress.

To the left, to the left

Here we go. Are you ready for it? It depends. I know, I know. Not what you wanted to hear, I’m sure. And to complicate things a bit more, Kanban does not have explicit rules about moving work left or right on your board. What I am about to share is considered best practices developed over many years of experience and heartburn. But as always, context is king. Now, let’s dive into this a little more to see if we can clarify a few things.

Unless the work item failed to meet the exit criteria for the previous state, I say this should stay in whatever state it ‘failed’ in. It would be a good idea to have the developer pair with the QA to fix the issue. This puts both sets of eyes on the work at the same time. Keeping it here allows it to stay important. If we move it back, we tend to “lose it”.

If the work items do not meet the exit criteria, they should move back to the left. One example could be the exit policy is explicit about the state of the code (EX: all code is clean, commented, complete, and deployed to the testing environment). When someone in QA discovers a defect because only part of the code was deployed to the testing environment, this did not meet the explicit exit policies for the previous state and could be moved back.

Unfortunately, this is not always what the system members want to do or are used to doing. This should also initiate conversations about potential improvements to the system. Why did we miss the exit criteria? What can we do to improve that? How can we avoid missing it next time? Do the exit criteria need to be changed?

A couple more things to consider. If the state the work item failed in (probably QA) is after your start point and before your finish point on the board, your cycle time will be unaffected. And while metrics are important, we shouldn’t be working a certain way just to satisfy our metrics.

Conclusion

In general, it is best practice to keep a work item in the state in which it fails. This ensures that the work remains visible and important, and it also allows for continuous improvement of the system. However, there may be cases where it is necessary to move the work item back to the left, such as if the work item does not meet the exit criteria for the previous state. In these cases, it is important to have conversations about potential improvements to the system to avoid missing exit criteria in the future.