Should We Move a Failed Story Back?
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.
Alter the definition of done
Testing should be parallel to development
When the developers are working on a story, they should keep checking in the code at each logical point (multiple times in a day). As soon as some functional part of story is complete, the testing should start. The developer continues working on other acceptance criteria in story and the tester continues testing and finding defects. As the developer is already working on the story, he immediately fixes the defect. This reduces the cycle time. The story is not done unless it is testing complete. This should be the responsibility of both the developer and the tester. There should just be one stage saying "In Progress" and then move to Done.
Only move forward
Re:Should We Move a Failed Story Back?
Visualize the workflow, then act on the information
I'd like to re-emphasize what Jeff Morgan wrote in his comment. Once you've got an accurate visualization of the workflow, that's not the end of the story. Now you have information that tells you where to look for potential process improvements. If you've got work moving "backward," then you can use the baord to find out where that's happening in the process, and change it. Don't just define it as "okay" and live with it.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015