Kanban Evergreen: Don’t move items backwards on the kanban board

When I started my Kanban adventure, I heard the sentence: “Don’t move your items backwards on the board”. 

The thoughts I had at that moment were pretty similar to the doubts I read about recently when preparing to write this article: why is it not advised to do so? What if we have a rework required? What if an item does need additional analysis or when a tester found a defect to be solved by a developer? 

Don’t transport your car 

The first answer, I received, came from kanban manufacturing, and satisfied me for a moment. Let’s imagine a car production line. If a defect was detected at the stage of installing the door but it was related to the earlier phase, the car is not moved back to the source of error, but rather kept in the place where the defect was detected. Instead, people swarm around it and try to fix the problem. 

The same way we keep the item on the board in the place where the defect occurred, mark it as blocked, create a new item (defect), and track it until solved – maybe even as an expedited piece of work. 

That made sense, but still addressed the problem only partially. 

The game changer 

Then, in the course of discussions, reading, and learning I was able to identify the problems with moving items backward on the kanban board: 

1/ you break the WIP limits 

2/ you lose the track of your metrics 

3/ you mess up the flow, and the lead time distribution is likely to become fat-tailed (risky, unpredictable & untrustworthy) 

4/ you violate the logic. A kanban board does not simply mean dividing your process into phases – “you map the series, or sequence, of dominant steps to discover new knowledge.”(1) 

The last sentence is the key to understanding why you should not move items backward on the kanban board. The current method of discovering new knowledge is the step where the defect was detected, and not where it was created. 

But let’s take a look at all of them. 

You break the WIP limits 

When you move a ticket backward, it is likely that you are moving it to an earlier state in the workflow that is already at its WIP limit. Moving a ticket backward is the equivalent of pushing it upstream, and the step in the process that receives it may find that it breaks the WIP limit; effectively the rework overburdens the system. 

Rework needs an explicit class of service – effectively the policies for what to do with items needing rework – leave in situ and request the necessary workers to expedite a fix, while blocking some existing work, is the highest class of service while sending the ticket backward to queue for rework where the problem was created is the lowest class. When you simply send a ticket backward and break the WIP limit, how it should be handled is ambiguous without an explicit policy – should it sit and wait until someone is free? Or should another item be blocked while the fix is made immediately? Or…? 

Keep an eye on the metrics 

Metrics are not tracked for budget holders or boring accountants’ satisfaction only. Because they are based on data, the metrics are a very solid anchor in understanding what happens in and with your process. They help not only analyse the past but also anticipate future patterns of your work items, flow, and even customers’ behavior. They make you predictable. 

Now, what happens to the basic metrics if you move the item backwards? 

We can show it the easiest way using Cumulative Flow Diagram. 

If we use the classic definition of CFD as “an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in the queue, and departure” (2), we can clearly see that moving items back will: 

• disturb the quantity of work in a given state of work – cause one item will be counted twice (or more) in one or more states; 
• affect the time and quantity in the queue – of a given (moved back) item but also the other items in the flow; 
• violate the arrivals – if an item returns to the beginning of a process; 
• CFD will make no sense anymore – until we make it a shallow metric to track input vs. output (and praying that our item will not move back to the “To do” list). 

Don’t ruin your flow 

Moving items back and forth mishandles your process. When you do it frequently, you will lose the track of your work. The first red flag will be metrics. And although lead time always works because it is only sampled at the beginning and end, the rework means that tickets don´t flow predictably and the result is a fat-tailed lead time distribution. Eliminating tickets moving backward is a key part of thinning out a fat tail to get to a predictable and trustworthy system.  

Very soon, your board will not tell you anything except for the fact that your work is in progress. The place where you visualize should be a single source of truth. A glance at your board should tell you immediately what happens. 

If items fly from right to left and back – how can you know, what happened to them, when you did not watch? How would you design your policies? Would you put there a limit of movements per week? When work items change their position frequently and randomly, how would you know, which phase did they hit already? You lose the history other than the oral narrative of the ticket. If you don´t have a tight-knit team then it is likely that the history of a tickets journey will be obscure and learning opportunities are lost 

Remember the knowledge discovery journey 

It is important to stop treating the board as a wall divided into columns that represent your work or people or specialist functions and handoffs between individuals and start thinking of it as a knowledge discovery process, which maps the state of the work, and the information we have about it. When you do this – map the work and knowledge discovery, your perspective changes dramatically. 

You do not want to move items backward, because – following the learning logic – that would mean that you have “un-learned” something. On the other hand, you do not want to manipulate or hide reality by keeping in development an item that really belongs to the analysis part. Indeed, the new knowledge, the learning, is happening where you discovered the need for rework. Moving a ticket backward implies you have thrown knowledge away, or unlearnt. This is unlikely. 

There are possible options for leaving this state: 

“Remember, the columns on a board (…) are an abstraction of the life cycle of learning that results in a solution to an end-user need. And all work can happen in all columns. The current column is just the dominant activity. It’s fine, for example, to have a development and test column and have testers working on some preliminary testing tasks while a ticket is in ‘dev’ and developers working on fixing bugs while it’s in ‘test’.” (3) 

Discuss with the team your current process. If you notice that you all feel a strong temptation to start this small movement exercise – react. Gather and think – why do you want to do this in the first place? Why did you think it’s the best idea that would reflect reality properly? The solution may be simple redesigning your flow, as the board is a living organism. (4) 

It is never easy, isn’t it? 

As you have probably noticed already, Kanban is very far from easy black or white answers. The same is applicable to the topic we discuss. Why is that? 

Remember that introducing the rule of “not moving items backwards on the kanban board” may be a very strong stressor to the current process. You may observe heavy resistance, especially at the lower maturity levels. So, sometimes, you may not want to do it. 

What you can do instead is allowing people to face the consequences of this choice (of moving items backwards). If they say: “we want to do this, you cannot stop us”, explain the expected outcomes and let people bear the weight of these consequences. When they realize where problems with metrics, transparency and communication sits, you can come back to the discussion about the root cause of these problems. 

It is important to ensure that the learning mechanism is in place to enable improvement. In low maturity organisations, let the tickets move backwards, ensure that explicit policy exists on class of service for rework, and ensure that metrics collection and reporting, together with a flow review (or service delivery review), and blocker clustering (or risk review) are all present and working effectively to drive learning. 

The class of service given to rework creates stress. The highest class of service “stop the line” and expedite a fix, is the most stressful, while “send the ticket back to queue for rework” is the least stressful. The resilience of the organisation matters. The “stop the line” approach will break in low maturity organisations that cannot handle stress it creates. Hence, the policy for rework, and whether or not tickets can or should move backwards needs to be tuned to the level of organisational maturity, and then refined and improved, tightened up as the organisation matures. The goal should be to get to a “stop the line” approach but only when the whole organisation is ready for it.   

What’s next? 

If you want to learn more about coaching improvement with Kanban, we teach this stuff during Kanban Maturity Model, and Kanban Coaching Practices classes. Learn how to coach the trickier issues in Kanban adoption, check out our schedule of classes! 

(1) https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/ 

(2) https://en.wikipedia.org/wiki/Cumulative_flow_diagram 

(3) by Paul Klipp at KanbanPoland slack channel 

(4) This is what happened to the process I worked in. We had 3 columns (analysis, design, development) where tasks tend to move back and forth. Short retro with the team helped to identify that our workflow required redesign. We removed ‘design’ phase and added ‘review’ after ‘development’ (which was the check with Business before testing). The problem of moving cards was solved.