Should We Move a Failed Story Back?

Posted by Dan Puckett on Dec 20, 2010

Sections

Process & Practices

Topics

Kanban ,

Agile Techniques ,

Lean ,

Agile Test ,

Agile ,

Testing

Share |

RELATED Research

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.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Alter the definition of done

   by Eirik Maus

   I try to practice that creating the proof that the feature works is part of creating the feature. The task is done when the new (automated) test case is integrated with the other requirements tests and runs successfully. Then you know the code is deployable with the new feature in place.

   Reply

2. Back to top

   Testing should be parallel to development

   by Piyush Kumar

   I have used most of the approaches on different projects mentioned in the article. If testing happens after the development is done, no matter whether you choose to move the card back or create a defect, it increases the cycle time. The developers might be working on something else and the defect might have to wait before it gets fixed. The testers might waste some time in this process as well.
   
   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.

   Reply

3. Back to top

   Only move forward

   by Jeff Morgan

   I personally like to replace practices that have the potential to allow work to move backwards in the value stream with practices that don't. Testing software after development is complete is one of these practices. I coach teams to create tests prior or at least at the same time as development. In this approach development is not considered functionally complete until all tests pass. There are other techniques I use to handle things like usability, etc. but won't go into them here.

   Reply

4. Back to top

   Re:Should We Move a Failed Story Back?

   by cao Alex

   Check your "DOD", if the story is test failed, it cannot move to "Done", it's status still is "doing" or "in progress".

   Reply

5. Back to top

   Visualize the workflow, then act on the information

   by Dave Nicolette

   IMHO everyone quoted in the article and everyone who has commented so far has said good things. I think it's important to use the kanban board to visualize the workflow as it actually exists. If things actually do move "backward," then go ahead and show that.
   
   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.

   Reply