When we think of flow, we often imagine water moving in a single direction. Ideally, our work items would follow a similar trajectory—whether it's from top to bottom, left to right, or right to left.
However, there are instances where an item could flow backward, particularly if it hasn’t met the exit criteria (i.e., conditions that must be met before a phase is considered complete).
For example, a work item might move from Build to QA without meeting all requirements.
In this example, the team chooses to move the work item backward in the workflow (as shown in the image below) until all requirements are completed.
Alternatively, if there's a shift in priority or customer requirements, instead of simply moving an item to the backlog, wouldn’t it be more logical to delete it?
After all, an unfinished work item holds no value. It’s true value is only realized once it’s in the hands of the customer.
To summarise, backward flow on our Kanban board is not a problem, but it should be reserved for rare cases. It should indicate a violation of policies and not be the standard process, but rather an exception.