What should I do with a Kanban-item that fails test?

Question

I have a basic Kanban-board, with a handover between Developer and Test:

----------------------------------------------------
| To Do | Ready |         Develop    | Test | Done |
|       |       | In Progress | Done |      |      |

Assume that I have put some limits on the board. What should I do if an item fails the test? It is not the testers job to actually fix the mistake, so as I see it, there is no way it can go to "Done". I want the tester to put it back in "Ready", but that is going to excede the limit an that. If the tester demotes an item from "Ready" to "To Do" he is basically undoing the prioritizing of the PO.

My soultion so far is to be okay with exceding the limit on "Ready", mark the items that have failed tests, and make them a priority.

Any other ideas?

Answer 1

I'd split Ready state to Re-Open and Ready. In this case you can clearly separate items that need re-work and new items. Items that need re-work usually should be handled first, so it will be clear to developers what is new and what is returned from Testing phase.

Answer 2

Several possible solutions (I'm sure there are others), including:

1) Flagging tickets in place, with the team expectation that flagged items (for whatever reason) get resolved as a matter of priority.

2) Moving tickets backwards. (But then does the board really reflect the state of the project? Do you also unwind the changes? Worth thinking about.)

3) Creating new tickets. Perhaps a special swimlane or a different colour for them.

They're not even mutually exclusive. Even if you stick with #1 (my default preference), #3 makes sense when the item is worth releasing even in its current state, and #2 might make sense if it's not so much a bug but instead a significant misunderstanding.

Further food for thought: lower WIP limits for dev, &/or add a limit spanning dev & test, further encouraging dev to support their work right through the process.

Answer 3

It depends on what you want to achieve. One option is to take a failure so seriously that you bounce a current work item to fix the bug.

I think your solution would be fine (make the failing mark really obvious).

And perhaps the real answer is to try it for a while and see how it works out.

Answer 4

I'm pretty sure what I'm going to describe in my reply will be very different from canonic Kanban. I mean, it might be very very arguable.

Never the less, since you asked for other ideas, I guessed you might be interested in heretical points of view as well. Should it not fit your case, please take it as a proof of concept.

First, a little overview to depict the metaphor I'm using. Take in consideration this short excerpt from the video you can find here

" Suppose a board representing at least two columns (for example, Doing and QA, but names are not important here) representing activities a programmer is called to do. Suppose this situation: Task B in the backlog and Task A actually in progress. When Task A is moved to QA, should the programmer work on Task A or move Task B to Doing and start working on it? We all know multitasking is evil, and programmer should not work on both task A and task B.

The right answer is: work on Task A first. Kanban is a pull system and would make this very clear: but even without Kanban, it's obvious that Task A is closer to be Business Value and should not be parked in QA column and moved to Done column as soon as possible. Waste should be eliminated and not stockpiled.

This begs the question: is there a Free Slot in Doing Column? Could another programmer move Task B forward?

The question is misplaced. If there's just one developer, the answer is no. Since programmer is not available, de-facto Work In Progress Limit of Doing Column should be decreased to 0. With 2 developers, the right question should be "Is the other developer available?"

The fact is: Work In Progress Limit is not a measure of Free Slots. The number of Available Developers is.

The board I tried to imagine uses another principle:a generic, personal and customized representation of a single programmer, like magnetic sticker. Call it Face. A programmer puts his face on a task to communicate he's working on that issue. Since each programmer has just one Face, programmers cannot commit to more than one task. Work in Progress Limit is not a measure of how many Free Slots are available: Available Team members, that is, Faces without a Task, is a good measure.

The rule is simple: Each team Member has just 1 face and can put it on just 1 task.

Yet, consequences are not trivial: using Faces it's easy to see who's working with who, how the team is clustering and who can be asked on a specific issue. "

In other words, what I think, then, is: WIP limit might not be the most appropriate measure of items you should put in a column, particularly when the sum of the WIPs of all the columns is greater than the number of developers (that is, the slots you actually can count on).

I believe that the same might apply to your case: in QA column you have a Kanban-item failing test. To me, there's no problem in moving it backwards in the doing column, the developer who was working on the failing item is still committed to it. Actually, you have a free slot.

I cannot understand why a WIP limit on Doing column should block your workflow. What should you do, otherwise? In order to respect an arbitrary number you wrote on the column, should you move the developer to another task? In the case you decide to abdicate and violate the WIP limit, shoudn't you call into question the meaning and the pertinence and applicability of that limit?

In short: move the task back, as long as you have a developer committed to the task.

Answer 5

The way I have done it in the past is to move the failed ticket back to "working on". Because it is predictable that many tickets will end up failing at the testing stage, you should build that in to the number of tickets allowed in "working on", and the number that you actually put in there.

For example, you might allow two tickets per developer for "working on", and permanently reserve one of those spots for failed tickets.

Answer 6

If the item has got as far as testing then looking at it one way, it's of a higher priority than anything else in the "to do" column, so could be put at the top of that column, bumping the bottom item off.

Or, could the tester take the item back to the PO and get them to re-prioritise it - so it essentially starts again from the to-do column? That's what the PO is for - they decide just how important getting the fix in is.

Answer 7

I believe you should have two sub-columns in the In Progress column. One should be "Actively worked on" the other one should be "Waiting" or whatever you want to call it. If a test fails, move it back to Waiting.

If you want to measure how many come back from testing (and this is a good idea), dedicate a sub-column to it.

Whatever you choose to do, make it under the "In Progress" area of the board.

Answer 8

The way I would handle this is to leave the story in testing but flag that it has failed. It will quickly become a bottleneck in the Testing column since testers will be unable to pull new items without breaking the WIP limit. This forces the team to swarm on that item to get it done (i.e. fix the problem & re-test).

Worth asking the following questions. Whose responsibility is it to do the development? Whose responsibility is it to test? Whose responsibility is it to re-develop in the case of failed tests? Hopefully your answer was "The Team".