A colleague and I have run a Kanban board at 2 places of work now, introducing a kind of scrum-ban agile/lean process into the team. Helping us move towards more flow orientated work and continuous releases.
I just wanted to ask your advice, that when a task is peer tested or tested by the test team further down the board, what should happen to the tickets where a fault is found? We’ve tried 2 methods:
-
Create a new ticket for the problem and chase this through the board until it catches up with the original faulted ticket. Then progress them both together through the board.
-
Move the original ticket back to ‘development to-do’ or ‘development work in progress’.
Does anyone have any suggestions on best practices in this situation?
1
Move it back. Agile development environments need to function based on their “definition of done”, and until the task is “done”, it doesn’t flow off the right edge of the board. In a good agile environment, “done” includes tested-for-unexpected-behavior and verified-against-requirements. Even better than the motherhood-and-apple-pie aspect of not polluting your board, it also motivates your developers to finish the task: “Darn it, the WidgetFrobulator is back in TO-DO again – I need to get it off the board!“
The answer to your question is simple. Do the version that fits your process and system best. Agile, and especially Lean is all about adapting the ideas to your team and to your process.
As for the 2 ways you mentioned, we did it both ways and we sometimes still do it both ways. For example if I have a Story in “Testing” on the board and one of my colleagues finds something wrong with it he will tell me immediately. In most of the cases these problems are trivial or relatively easy to fix and they will be fixed. Sometimes even the tester can fix the problem. Also, we have to consider that the story is in the last stage before being “Done” and it is usually best to make it so. Fix the bug so that the story can be finished and considered Done. One Done story is much better than 2 unfinished ones.
On the other hand, sometimes, but very rarely, a fundamental problem is discovered in the last stages of that story. When this happens more work and time may be required and you may be already half-done with the second story you started meanwhile. In this case you can again choose to finish the story that can be done faster and add another task to “catch up” with the bogus story or bring it back on the board, as you wish.