Don't let things move backwards on the board

I think that using Scrum with Kanban is the best of both worlds. You get the collaboration, inspection and adaptation that comes from the Scrum events, artifacts and accountabilities, and you get the improved flow and rigor that comes from using practices from Kanban such as limiting work in progress and being thoughtful about how you visualize your work.

One practice from Kanban that I think is often overlooked is related to the flow of work. Work on the Scrum board should flow from left to right - but it shouldn't flow backwards.

Why is that?

When work moves backwards on the Scrum board, it creates some very real problems which undermine the transparency of the Scrum board and cause unnecessary churn. For example:

• It tempts you to break work-in-progress (WIP) limits. Imagine an item moves from Development to Testing, but the testers find a lot of bugs. Do you push it back to Development even though the WIP limit there is already maxed out? If you do, you’ve broken the WIP limit. If you don’t, you have to live with the reality that the work is sitting in Testing longer than you’d like—which is exactly the kind of signal WIP limits are designed to highlight. Keeping it in Testing makes the problem visible.

• It blurs where the real problem lies. When you push work backwards, you hide the fact that Testing is overloaded or that the quality isn’t where it should be. Instead of seeing “Wow, this item has been in Testing for five days because it’s buggy,” the board just shows it bouncing around. Forward-only flow forces the team to deal with the bottleneck rather than masking it.

• It makes metrics meaningless. Cycle time and lead time are only useful if work flows forward. If an item goes back and forth, your data gets polluted, and you can’t use it for forecasting or improvement.

• It undermines focus. When a work item is pushed back, it creates a washing machine effect - a buzz of work moving back and forth which is distracting.

• It creates noise instead of transparency. A board that only moves forward shows patterns clearly: “Here’s where work is slowing down.” When items hop backwards, it’s hard to see the real issues. Transparency isn’t about showing motion; it’s about showing reality, even if that reality is uncomfortable.

In other words, backward flow weakens the very benefits of combining Scrum with Kanban. A forward-only board makes bottlenecks visible, enforces WIP discipline, and tells the truth about how work is progressing—even when that truth stings a little.

For a better understanding of why limiting work in progress is so effective, signup for Rebel Scrum's upcoming Professional Scrum with Kanban course.