Kanban board - How to handle defects found in testing phase?

I have a question regarding kanban board and handling defects that are found in testing. The case is this:

- User story moves through "Development'' and goes to "Testing'' column on board. Defect is found in the period of testing. Where should that US be held now?

a) In the same column and flagged but with new status - maybe "Defect opened''

b) Returned back to "To do'' - but then we go LEFT instead to RIGHT on the kanban board

c) In the same column with the same status "Testing''

@Jovan Jakovljevic, kanban helps make WIP transparent. If the item has moved to the testing column and a defect has been found, why can't the available team members swarm to address the defect, so that testing can continue, the bottleneck removed and flow restored?

@Steve Vb, yes, I think that's the best approach. My concern is task switching from the development side. If the developer started new implementation on the User Story, and the defect occurs, should we then prioritize that defect in order to unblock the flow?

My concern is task switching from the development side. If the developer started new implementation on the User Story, and the defect occurs, should we then prioritize that defect in order to unblock the flow?

@Jovan Jakovljevic, My understanding of kanban has always been about keeping the flow of value constant. Its like thinking of a clogged vs. unclogged pipe.

When bottlenecks arise, the idea is that the team members swarm to resolve the bottleneck so that flow is restored. You wouldn't want WIP to keep accumulating in any one column. 

I have a question regarding kanban board and handling defects that are found in testing. The case is this:

- User story moves through "Development'' and goes to "Testing'' column on board. Defect is found in the period of testing. Where should that US be held now?

What are you trying to measure?

What are you trying to measure?



I am not trying to measure anything, what I want is to team focus on unblocking things and when defects are raised on the US, for me that is a blocked column. So basically, team should focus on fixing and getting to DONE column. Task switching is the challenge, but team should focus on moving things not on individual tasks getting done.

The concept is about continuous flow, which is why most Kanban boards have the team work Right to Left Top to Bottom. Getting things Done is more important than starting new work and getting them ready for testing.

If swarming is introducing a context switching problem, team needs to figure out ways to prevent it from happening. Swarm on the causes for context switching. Identify the patterns of the bugs and help prevent them. Are the stories too big and/or too complex? Most teams attempt to have each story of work be no longer than one day of implementation, and that's to help keep the work small and focused.

I am not trying to measure anything, what I want is to team focus on unblocking things

Do you hope to achieve predictability in the way this work is carried out?

My concern is task switching from the development side. If the developer started new implementation on the User Story, and the defect occurs, should we then prioritize that defect in order to unblock the flow?

I feel that this is the issue your team needs to be working to resolve.  As almost everyone has discussed, the goal is to get the top item on the board to completion before starting new items.  When something, anything, everything prevents the top uncompleted item from moving forward, the team should focus all of their attention on getting it moving again.  If the developers are starting Item B immediately following their declaration of being code complete on Item A, they will have to learn to deal with context switching because it is inevitable based on their actions if all testing occurs after that code complete declaration. 

I know, that this thread is one month old, but maybe someone else find it and need a answer of that question, what he/she shall do in that situation. This situation is also mentioned in Klaus Leopolds book about Kanban.

What you shall not do is:

• Ignore it. Testing is an activity, and if you test the PBI, you have done your work and can push it in the "Done" column. After that, you create the defect as a new item (bug) in your backlog. 
• Bring it back to the activity, (for example "implementing"), where the blockade can be fixed.

The flow is only going in one way. What you shall do is to mark it as a blockade (with a sticky note) and fix the defect. Collect all sticky notes of blockades.

If this happens only one time, than you can ignore the blockade. If you collect a lot of such sticky blockade notes, you shall discuss this with your team, why testing sometimes fails.