This is the question which I hear very often: should we move back cards on the Kanban board when we realize the feature isn’t that advanced as it looks like? A typical example may be about feature which has been developed and is being tested and it appears some bigger patch has to be applied. Another, more interesting one, may be about feature waiting for someone outside a team, i.e. waiting for client’s decision.
So, coming back to the question, should we move back cards?
I always answer that is isn’t forbidden, so it is a subject of rules agreed by the team, but I don’t think it is a good idea. Consider a simple situation:
You have development column full and it appears one of cards from testing should be moved back, so you break the limit. On the other hand you don’t want to move the card back to todo column since it isn’t a feature which is 0% done. It just has to be changed or has to wait for something before a team can perform further tests.
OK, the simple answer is that you should avoid moving cards back and do whatever it takes to clear the feature out of the board while the card stands where it is. As long as you have all the tools to do the job this approach works pretty well.
However, sometimes you don’t have control over the feature anymore. One of teams I’m working with has pretty complex deployment process. To make the long story short we have to wait until the customer performs some task to be able to move further. The part of the process is out of our control. Be it waiting for clarifications regarding a bug or completing acceptance tests for a feature to give a couple of examples.
Now if we put features we really work on along with those which were waiting for some external input in the same column we’d end up with crazy high limit. That is as long as we cared not to break them every now and then. We may have a couple features which we are actually fixing and a dozen of them which are waiting for client. And setting the limit of 15 doesn’t sound like a good idea if you ask me.
We solved the issue by setting additional todo queue within the column. It works as priority queue, so if we look for features to work on we consider cards from the priority queue first and only then from the previous column.
Feature B would be taken before feature D. Additional trick we needed was to visualize which features in priority queue were ready to go and which were still waiting (small sticky notes attached to cards can be used for that).
Thanks to this approach we can have reasonable limits in every column we have control over. What more, mechanics of the board forces us to finish the older tasks first. If there is a task in priority queue which isn’t blocked anymore it we start working on it before we move to regular stuff.
The downside is we have some hidden work in progress which isn’t limited in any way. But at least we make it visible and get rid of it as soon as possible. And we don’t move cards back which always create some mess.
One final advice: if you face this kind of situation once a year don’t bother to rearrange the board. You will need adjustments if, and only if, it is a common issue in your team.
Read the whole Kanban Story.