Eric Willeke was pondering what to do with a story on the Kanban task board when that story fails testing. Should he move it back to "Development" or leave it in the "Testing" state? He came up with a few different possibilities:
- One is to integrate dev/qa responsibility into the "done" state so that there is no movement, only conversation and agreement on when it can be moved. That can be facilitated by having a series of expanded tasks that individual devs/testers take on, but knowing the story's not done until everybody agrees all the tasks are done.
- Another is to move the story to test, move it back, move it forward, etc. If that's what's happening in real life, that's how you should model it.
- Another is to have a "defect" flag (or bug cards) on the item, but it stays in test, with developers coming in to help solve them until they're all done. If this better fits the actual model of what's happening, you should probably model it that way.
Thierry Henrio offers a different approach, using a concept borrowed from Lean manufacturing—"red bins":
I experimented one like option :
- have a dedicated red bin for each stage, located at top bottom of board
- when cause is listed in one stage check list, move it there
- we have 30 mins to get out of red bin
This worked well for cause in control of team. When cause is upstream, then 30 mins policy was dumb, and it reduced its effect.
Dedicated red place (bin) is a stronger visual effect than a red flag.
Ron Jeffries gives an example of when cards should flow upstream on the task board:
[...] if the work went back to some person who already worked on it and was supposed to be done, then flowing upstream is one good way to model what happened.
No matter which method you use, though, Adam Sroka advises that your board should represent reality, not some ideal state:
The idea that we want to model what we do and not what we would like to do is subtle but extremely powerful. To me this was the biggest revelation about Kanban I got from David's coaching workshop this Summer. Visualize what you do now. Then introduce explicit WIP limits, look for improvements, etc.This has worked very well for me. I also come from an XP background, and I see visualizing flow as a kinder gentler way to introduce change. I used to want to change everything on day one. Now I realize that I can make progress simply by helping people be honest (with themselves) about what they currently do.