Moving Items Backwards on a Kanban Board
DZone 's Guide to
Moving Items Backwards on a Kanban Board
Join the DZone community and get the full member experience.
Join For Free
A question that comes up a lot and is discussed at great length during Kanban conferences is whether or not you should move an item backwards on a Kanban board. Sometimes an item will have made it to the implementation station, but for some reason needs to be redesigned. If the team wants to move it back to the design station, or even the analysis station, what should they do? The
kanbandev Yahoo group had several strategies and suggestions for this kind of situation. Although there's no single right answer, there are several factors teams should take into account.
Moving Cards Backwards
Many Kanban practitioners find it easier not to allow items to go backwards at all. Even if you do decide to move an item backwards, it is still recommended by some that you don't violate the WIP limits. It could cause a work-overload if you have too many cards in one column. However, if you're still hell-bent on moving that card back, try moving back the lowest-priority item from the column that's receiving the backward-moving item. Repeat that strategy if there's full-capacity on the column getting the low-priority card as well. The chain reaction will seem like a combination shot in billiard balls with each successive card getting knocked back by the
previous one. Obviously, this can be disruptive if you're not careful. Some users of Kanban won't say that WIP limits must be followed at all costs in any situation. If finishing a feature in its current form doesn't make sense, the team should push it back. Some teams don't mind pushing an item that needs "rework" to an upstream station. Another strategy is to push the item two steps upstream, marked as "ready to pull" regardless of WIP limits.
Strategies That Don't Involve Backward Movement
There are a few tactics that don't involve moving back the card that needs to go through a specific station again. You can turn one station into a rework station and just move the bug cards to that station while the item remains in its current station (however, this process doesn't necessarily involve bugs everytime). The "rework" card can even be colored differently as a visual indicator. Work can continue on the item remaining 'in situ', but the bugs should be treated as an expedited request so the system doesn't stall. This system can be faster than moving an item back and it doesn't break the WIP limit, but it can also lead to swarming behavior. There are Kanban applications that can mark a card as "blocked" when entering a rework. The user can enter a reason and email notifications can be sent out. In extreme cases, you should tear up the card and reconsider the value and approach. After that, the team can try putting it through again. In certain contexts, it's better to either 'tackle them' or 'destroy them.'
Why Did You Need to Move it Back in the First Place?
Teams generally find it necessary to do a root cause analysis when they feel that they have to disrupt the flow of the Kanban board by sending items backwards. If sending a ticket backwards has negative consequences, the team will usually change their policy to leave cards in place. If "stop the line" side effects from fixing a problem 'in situ' become problematic as well, then the team will start to think about prevention and pursue root cause analysis. Teams must ask themselves: "Why did a card move downstream prematurely?" and "What can be done to keep it from happening again?" Some teams will allow their cards to move backwards, but they will flip them over to add a timestamp and record the reasons behind the move. The team can come back to the record later and reflect on these issues in their retrospectives, which should be done on a regularly occuring cadence.
A Question of Policy
There are many variables to consider when a team decides if it should move an item back or not. It depends on the organizational maturity, the type of work you're doing, the organizational culture, and the risk profile of the project. The decision to either leave an item in place or to send it backwards is ultimately a judgement call and a policy choice. Whether or not you allow the WIP limit to be exceeded while doing so, is also a policy choice. You don't have to be right every time. That's why teams go back to the mistakes they made and modify their policy. Once the team has a policy that is explicit, transparent, and works well in most situations, they need to stick to it. Policy should be your guide when dealing with work that is blocked or defective.
For more information on Kanban and Limited Work-in-Progress, visit the Limited WIP Society website.
Moving Cards Backwards
Many Kanban practitioners find it easier not to allow items to go backwards at all. Even if you do decide to move an item backwards, it is still recommended by some that you don't violate the WIP limits. It could cause a work-overload if you have too many cards in one column. However, if you're still hell-bent on moving that card back, try moving back the lowest-priority item from the column that's receiving the backward-moving item. Repeat that strategy if there's full-capacity on the column getting the low-priority card as well. The chain reaction will seem like a combination shot in billiard balls with each successive card getting knocked back by the
previous one. Obviously, this can be disruptive if you're not careful. Some users of Kanban won't say that WIP limits must be followed at all costs in any situation. If finishing a feature in its current form doesn't make sense, the team should push it back. Some teams don't mind pushing an item that needs "rework" to an upstream station. Another strategy is to push the item two steps upstream, marked as "ready to pull" regardless of WIP limits.
Strategies That Don't Involve Backward Movement
There are a few tactics that don't involve moving back the card that needs to go through a specific station again. You can turn one station into a rework station and just move the bug cards to that station while the item remains in its current station (however, this process doesn't necessarily involve bugs everytime). The "rework" card can even be colored differently as a visual indicator. Work can continue on the item remaining 'in situ', but the bugs should be treated as an expedited request so the system doesn't stall. This system can be faster than moving an item back and it doesn't break the WIP limit, but it can also lead to swarming behavior. There are Kanban applications that can mark a card as "blocked" when entering a rework. The user can enter a reason and email notifications can be sent out. In extreme cases, you should tear up the card and reconsider the value and approach. After that, the team can try putting it through again. In certain contexts, it's better to either 'tackle them' or 'destroy them.'
Why Did You Need to Move it Back in the First Place?
Teams generally find it necessary to do a root cause analysis when they feel that they have to disrupt the flow of the Kanban board by sending items backwards. If sending a ticket backwards has negative consequences, the team will usually change their policy to leave cards in place. If "stop the line" side effects from fixing a problem 'in situ' become problematic as well, then the team will start to think about prevention and pursue root cause analysis. Teams must ask themselves: "Why did a card move downstream prematurely?" and "What can be done to keep it from happening again?" Some teams will allow their cards to move backwards, but they will flip them over to add a timestamp and record the reasons behind the move. The team can come back to the record later and reflect on these issues in their retrospectives, which should be done on a regularly occuring cadence.
A Question of Policy
There are many variables to consider when a team decides if it should move an item back or not. It depends on the organizational maturity, the type of work you're doing, the organizational culture, and the risk profile of the project. The decision to either leave an item in place or to send it backwards is ultimately a judgement call and a policy choice. Whether or not you allow the WIP limit to be exceeded while doing so, is also a policy choice. You don't have to be right every time. That's why teams go back to the mistakes they made and modify their policy. Once the team has a policy that is explicit, transparent, and works well in most situations, they need to stick to it. Policy should be your guide when dealing with work that is blocked or defective.
For more information on Kanban and Limited Work-in-Progress, visit the Limited WIP Society website.
Like This Article? Read More From DZone
Topics:
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}