In Kanban, What should I do if the card has a bug that need to be fixed in Test column?

Question

Let's say the workflow is something like this:

Todo -> Development -> Test -> Release

If some feature has done in development and moved to test, when tester found a bug, may be app crashing or similar things, what should I do to that card? Is it the right way to leave that card in there and developer need to stop his current development to fix it first? If so, does this mean that developer has to prioritize this test first (to let the flow be able to continue.) and developer must be interrupted all over the time to clear the bug in test? Is this really better than move the card that has bug back to todo phrase?

Answer 1

That's a great question and a topic of much debate in Kanban communities! However, there are two aspects to this - one, what is your actual engineering practice when a defect is found during development (as opposed to production defects) and two, what is the way you want to model that on your Kanban board.

A developer works on a feature - which may be modeled as a User Story or an Enhancement or a Change Request - and during its development lifecycle, issues or bugs may be found during various testing stages (unit, system, integration, etc.) as well as code reviews - and these issues may be captured/ reported as Defects or Bugs or Issues.

Without getting into your specific processes, there are broadly two methods of modeling this on a Kanban board that teams use.

The first one is, depending on the stage where an Issue or a Bug is reported, the User Story is moved back to the earliest Working stage (Design In-Progress or Dev in-Progress, for example) and reworked on to fix the Issue or Bug.

The second one is, where the User Story is 'blocked' wherever the issue or bug was reported and a new issue or a bug is created as card and taken up for work at the earliest stage it needs to be taken up in (including perhaps in a completely separate swim-lane with its own workflow for fixing such issues or bugs. In the picture below, cards with the red square represent blocked user stories - which are then linked to their associated defects.

The process typically favored is the second option, since it has the following advantages -

1. It clearly highlights and visualizes the stories which are blocked due to defects being found in them.
2. It specifically identifies and allows 'assignment' to 'failure-demand' - and enables analysis of this failure demand.
3. It allows you to model a different workflow/ process for issues/ defect resolution if you wish, in a separate swim lane, which further helps the analysis of cycle time (resolution time), throughput and other metrics which might help you make SLA commitments to your customers.
4. If your team is focused on implementing and following WIP limits, it puts pressure on developers to resolve and close open defects against their name since blocked items also occupy their WIP limit.

You do have to make sure that developers follow the process of linking (associating) stories to their defects/ issues (which a Kanban software would usually enable fairly easily) and also to unblock the user story when the defect is closed, so that the developer's WIP limit opens up for doing additional work.

There is a very nice blog post written by Kanban thought-leader Dr. Masa Maeda on this topic you might also be interested in looking at - how to handle tickets during sprint planning Hope this helps!

Answer 2

Obviously, to start with, if a bug of this nature is found "in test," the item needs to be moved back to development. The priority of then handling the fix/re-engineering in development should be based on the importance of the feature of which this defect is a disruptive part.