0

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''

1
  • Just move it back to To Do - sounds like you're making it much more complicated than it needs to be? (kicking a card left instead of right isn't a sin...). Cheers – jleach Sep 22 '19 at 23:36
7

The ticket should be in the column it belongs in, which sounds pretty stupid to say and is exactly why I'm mentioning it. The ticket was being developed, then handed off to QA who found some defects. The ticket now goes back to an engineer to be fixed. Thus, the ticket should go back into development. Each column has a group of people or teams that are responsible for getting that ticket into the next column. It's not QA's job to fix the issue, so it should go into the column meant for engineering.

It's a good idea to use labels to mark tickets which failed to pass QA or failed to pass acceptance testing from the product owner. Obviously the ticket should contain information regarding why/how it failed the test with some context around what needs to be fixed.

3
  • I think that US should stay in Testing but gets blocked (in whatever way you do this). You then create a new card/item/ticket of type Defect (or different coloured Post-It or whatever) which then moves through your normal process. Once that defect ticket gets to Done, you unblock the original story and continue work on it. – DarkKnightSM Sep 17 '19 at 18:58
  • 5
    @DarkKnightSM I've seen that method used but I don't think it's appropriate -- the original ticket was not properly fulfilled and needs to be reworked. Creating new tickets to track development errors pre-release causes clutter, especially since a big purpose of tickets is to split up the work among team members. It's up to your team but speaking from experience, putting the results of testing in the ticket and kicking it back to the in progress/dev column is the most intuitive and quickest way. – Jesse Sep 17 '19 at 19:10
  • 1
    If the defect is so severe that it requires a new ticket to fix then the original ticket was not written correctly and that seems like a process problem not a development problem. – Jesse Sep 17 '19 at 19:11
0

We often use a column within our Scrum boards which reflects the fact that amends are required or testing has failed. It will sit here until it goes back into the "in progress" column when a developer starts working on it again. In our case it sits before the "to do" column, but could be in any order.

0

First of all I would agree with everyone who says don't overcomplicate it. Work with the team to decide how the board can best reflect the status of work to be done.

But if you look at the history of Kanban, the Toyota production system might give you an idea: When a defect is detected, the workers pulled the "Andon Cord", which stopped the production line until the cause of the defect has been found and removed. So in your case I would suggest the following: a) Block other tasks to going into progress, until the defect has been fixed, or otherwise limit the amount of WIP you can have. b) Ideally you shouldn't have dedicated testers and developers anyway, so have the team "swarm" around the issue to until it satisfies your Acceptance Criteria or Definition of Done.

What you don't want to have is a ticket that bounces back and forth between QA and In Progress. This eats up time and frustrates everybody involved.

0

The purpose of the Kanban Board is to visualize the work. Therefor, the question for you is what helps you improve your process more effectively. If you create a new card for the bug and let that move through with the overall item sits in testing, that provides a certain type of visibility. If you mark the card as blocked until all bugs are resolved, that provides another type of visibility. In my experience, moving the card back to Dev is actually confusing to follow because the way most people do it, I can't easily see if something is in dev for the first time or the 5th, but if you solve this problem, maybe that actually gives you more visibility. The goal of all of this is so you can see how work is moving through your system and improve it. The right thing to do is the thing that helps most in that effort.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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