6

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?

Allan Kirk
  • 63
  • 1
  • 4

8 Answers8

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.

Michael Dubakov
  • 1,560
  • 3
  • 16
  • 25
  • For now I only have a rather small board, so adding even more columns is not an option, even though I would like to. I have added a noticable marker to the failed items, so they should get priority. – Allan Kirk Feb 28 '12 at 10:10
  • @Michael Dubakov: So how do you deal with physical cumulative flow diagram? When you move the developed item into test you update the development line,and after a while that item comes back to the Ready section and you start working on it.How do you calculate the velocity when a half-task is coming to the game again?What is your idea about estimation in this situation? – Mohsen Apr 26 '16 at 14:12
0

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.

Mita Ka
  • 317
  • 5
  • 8
0

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".

Stephen Clay
  • 107
  • 7
0

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.

asplake
  • 177
  • 4
  • I don't like option 3. Create new tickets will be painful to track. – Michael Dubakov Feb 22 '12 at 13:00
  • I don't like it either, but it does reflect what many teams already do. "Start with what you do now" and all that. – asplake Feb 22 '12 at 13:56
  • I don't want to force a failed item back on the same developer right as it fails, as that is "push" in my opinion. It could also lead to a situation with severe multitasking on one developer while another sits idle. I'm going to move the ticket backwards for now, and flag it. – Allan Kirk Feb 28 '12 at 10:15
  • I wanted to make it clear that there's more than way to do it; use the approach that works best in your context. That said, I prefer 1, where the wall shows most accurately both the state of the codebase and *what the work needs*. It's not push; what gets selected next and by whom is for your policies to help decide. – asplake Mar 26 '12 at 08:29
0

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.

Steve Freeman
  • 2,707
  • 19
  • 14
  • I wan to avoid bouncing items, as that will undo the work of the PO: The tester now decided which of the items in the queue is to get bounced, and thus they are doing prioritization. I'm going to try my solution for a while, and see what happens. – Allan Kirk Feb 28 '12 at 10:08
0

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.

Arialdo Martini
  • 4,427
  • 3
  • 31
  • 42
0

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.

Jonathon Jones
  • 711
  • 6
  • 8
  • 1
    The thing is, no matter how I put the limits, I can imagine scenarios where those limits gets exceded. In this case, I can imagine a developer finishing 3 items, and picking number 4, but then all of the three first fail testing, and suddenly the programmer has 4 items assigned to him. – Allan Kirk Feb 28 '12 at 10:05
  • I don't think that would be possible as long as you keep at least half of the available space open for failed tickets. – Jonathon Jones Mar 06 '12 at 16:12
0

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.

Amykate
  • 485
  • 5
  • 8