Given that you have a feature tracking through your Kanban board, the dev marks it done, it's pulled into QA, and the dev pulls in new work.

QA fails the item.

Now what? You can't move it back into the dev stream as it's full. You can't move it forward into Deployment as it's not working properly.

Where does it go? Or does it go all the way to the left to approved tasks with a high priority, for analysis to pull in and add any details to it, and then for devs to pull in from there? Assuming your flow looked something like:

Backlog -> Start -> Analysis -> Dev -> QA -> Deployment -> Done

  • 1
    Great answers so far, thanks. I really hope we implement this well here...and people realize that we can change the system to our needs, not the usual "this is our process, deal with it" mentality.
    – CaffGeek
    Commented Nov 24, 2011 at 14:53

5 Answers 5


Since one of Kanban rules is to make policies explicit you should define what exactly "QA" stage in your process means and what kind of activities it covers. One of common approaches is that such stage covers both testing and fixing bugs, which means that it is perfectly normal to work on the code, namely fix bugs, when a feature is in QA stage.

Of course you can choose an isolated approach as well, where unless feature is fully tested and decision is made whether it is good or not nothing in code changes. Note however that such approach basically hampers the flow as you create formal, and possibly multiple, hand-offs during testing/bug fixing stage.

Thus, my first advice would be to treat your QA stage as the one covering both testing and bug fixing which basically renders the problem of moving index cards anywhere irrelevant.

Additionally, since basically you should first deal with the features which are closer to completion a team member should first deal with any bugs they do have in features being tested and only then move to new features.

Note: that I don't necessarily consider that a feature, which we found bug in, should automatically be blocked. If this is rather common situation I wouldn't do that. If you overuse blockers they don't have that much of value anymore. Besides, the question is: do you really need to treat it as emergency and swarm over a feature when just a couple of bugs are fund there?

Other ideas to deal with the problem:

  • You may think of moving cards back but personally I don't recommend it. It just adds a lot of hassle. You can have policies that you can violate limits in such situation (as Siddhi suggests) but still I'd say the chaos it introduces isn't worth the value you may gain.

  • You may "park" features which didn't pass testing. You may have dedicated subcolumn where you put such features so everyone knows that they require bug-fixing. Additionally you may decide whether these features count to your limits or not. I wrote more on such approach here.

  • You may just visualize status of testing, e.g. testing started, testing passed, testing failed, with additional visual signal and keep the index cards in QA column. You get the same information you'd get with moving cards back but it doesn't introduce chaos to the board. I mentioned and described such approach here.

  • You may deal with bugs using additional information radiator, usually not a full-blown Kanban board. Then, again, you keep the index cards in QA stage but you deal with bugs independently. Joakim Sunden shares a neat method to deal with such tasks.

Either way my advice would be to start with a simplest possible method which seems to work. You probably neither want nor need a complex tool to cope with the problem, thus the first idea to just define the process in a way that makes the issue non-existent.

By the way: QA comes from Quality Assurance which is way more than testing or QC (Quality Control) which is what you seem to do in your QA stage. Read more here.

  • 1
    +1, great answer, I never even thought of it like that. That you can have an item stay in QA when it fails, and just move your focus from dev to QA to fix the bug, then back when it's ready for QA to look at it again.
    – CaffGeek
    Commented Nov 24, 2011 at 14:38
  • 1
    +1 I think a lot of people get hung up on the board columns being like job titles when they are really just stages in the process. Developers work in the QA stage when they are fixing production defects.
    – Jamie
    Commented Nov 24, 2011 at 17:46
  • 1
    +1 This is a very sensible solution and the one I will implement. x1000 Thanks. Commented Nov 25, 2011 at 18:38

There are many ways to deal with this. But before that, remember that there are no 'rules' in Kanban -- it is just what your team decides. For example, you say you cannot move the card back because the WIP is full. Well, if your team creates a policy that you can override the WIP when a defect is found, then thats your team policy and now you can move it back :) (just make the policy explicit so that everyone understands and agrees to it)

Now the options

  1. I mentioned one option above - move the card back. You can agree on a team policy that defects can override the limits in upstream lanes
  2. Another option is to mark the card blocked and leave it in the QA lane. If you look at the board right to left, then the first action is for team members to swarm & resolve the block in QA before continuing with the existing work
  3. Third option is to mark the card blocked, and create a new card (maybe in a different colour) to track the impediment.
    1. The new card can move through the same lanes,
    2. or it could jump certain lanes (analysis may not be needed for example),
    3. or you can create a swimlane just for the impediments to flow, maybe with columns Not Started->In Progress->Done. If you create a separate swimlane, you can use that to track any impediment, not just defects.

Which option you choose depends on your situation.

If you choose to block the card in the QA lane, then the card will be occupying one spot in your WIP limit. So while the block exists, you may have a tester free. If the team is cross-functional, that person could perhaps help out upstream in the system.

If you prefer not to block up the WIP in QA (ie, have the testers continue testing other cards at full WIP), then Option 1 might be for you, as it frees up the QA lane.

If you have a tight cross functional team, swarming might be the best option. The card gets blocked, tester & dev pair up, the defect is fixed, and it moves on. Shortest lead time. If you have handoffs, then Option 3 gives you more visibility.

The important thing here is to implement one of the options and then keep taking steps to improve the system. Don't be content to just say, okay we can now handle defects on our kanban board, and leave it at that.

For example, if you have handoffs and implement Option 3 to get visibility into the time taken to fix bugs, then look at that and ask: How can we shorten this feedback loop? Can we bring testing & development into closer collaboration? If you see a lot of defect cards generated at the QA lane, then ask: Why are we generating these defects, and how can we fix it? Should we implement acceptance tests up front? .. and so on.

  • 2
    I would recommend using the second option. Allowing to move cards left can create a mess on your board and in if you've exceeded the limit in the Dev column it would be impossible to move it back anyway. Another thing is swarming. Don't start with overriding your limits. Keep to them and observe what happens. Overriding the limits is often working against Kanban rule - Limit WIP. And now the best part of this answer - read the board from right to left. This will help you finish the task that got further in your process before starting new ones. It pays. Commented Nov 24, 2011 at 7:01

Pawel answer is great. I just published a simulation that visualizes how manage a mistake - check it on slideshare.

These are three of the possible options to manage a mistake (more are available)

Blocked work Option 1 Option 2 Option 3


We have similar situations in Sales and Marketing department in my company. When a salesperson was trying to sell our services. We dealed with it by dividing Done column into: Failed and Accomplished. This way we could get more information from analytics. We have also tried to archive tasks in the column when something with the sale didn't work out and to create another task/card with a special tag.


I strongly agree with the approach to keep task in QA/Review column. From multiple viewpoints:

  • Priority - Tasks on the right side should be more important. More attention from the team to finish it. If in QA (maybe marked as blocked) this should be resolved before any new ticket is being worked on. Knowledge will still be fresh. If necessary swarm, pair program.
  • Simplicity - Process is easier to follow. You can measure the time of the tasks that are in the QA lane instead of measuring how many times task moved back from QA -> DEV. From the First Way of DevOps, reduce handoffs.
  • Collaboration - When the task is in QA lane I expect higher collaboration between QA and Development members if this is the case in the team.

Learning and improving - IMHO its crucial to strive for 0 rework needed. Reflect on why it happened in the first place:

  • Missing requirements?
  • Not enough analysis upfront
  • Missing experience
  • Lack of collaboration with PO/QA
  • Lacking the tooling to properly test functionality locally.
  • Not enough testing efforts from implementors

Can you improve the process with:

  • Pair programming during the development process?
  • Spending more time on defining requirements with happy path and multiple edge cases
  • Do you need to improve test data
  • You need explicit DoD in place?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.