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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
11 comments… add one
The problem with such approach is, as you have said, that we have a subcolumn with no limit at all. And it will be very easy for the team to do stuff like: “Oh, we reached the limit in the test column, so let’s move one of the features to de subcolumn, and everything is ok”. Although this approach might be very useful it’s also a little tricky.
On the other hand it shows us one more hint about Kanban Board, which my team was not aware of in the beginning – you should read the Kanban Board from right to left. If there is a task in Test column assigned for you and there is a task in Dev column assigned for you, you should start with the Task from the Test column.
Problems with abusing priority queue should be non-existent since there should be clear transition criteria, i.e. you move a card there if and only if the feature is blocked by the client for longer than a couple of hours. Then the team either respects the rules or the problem of parking features in priority queue is the least important of your issues.
You’re totally right with reading the board from the right side, when looking for job to be done. If feature A is to the right from feature B you have shorter way to complete it, thus limit WIP, thus limit waste. It also mitigates the risk of having the board blocked because of a few features in one of later stages of the process which are covered by no one.
Hi Pawel,
This is something I’ve done a lot of thinking about, and discussed with several people in my department. My view is that, since a Kanban board is a framework for detecting problems with flow, I prefer to leave items in the column in which they’re blocked. This will then show up on the CFD as a throughput constraint, which can then go through a process of root-cause analysis.
The bottom line is that that card (or feature etc) has not been delivered to the downstream customer, and that is the most salient fact.
Most of my thinking and discussions have centered around rework based on issues found by testers (and wanting to measure the amounts of rework) so in the scenario you mentioned of a deployment being ‘out of our hands’ then this thinking might not apply.
I might be doing it wrong, but when I discover a new state, I add a new column. E.g., in one context, we had things that were legitimately interruptive. If a card was, due to an interrupt from something more urgent, no longer being worked on, we’d move it to the “on hold” column.
For me, the major utility of Kanban is forcing ourselves to see things very clearly. To achieve that, I focus on representing the true state of things.
@Wiliam
If I understand Pawel correctly this subcolumn, must be part of the same column. You can call it overlflow section if you want, but it’s overflow not generated by the team. Imagine following scenario: You are to develop 5 features and you started with A and B, but during development you encountered an issue that is beyond your decission – it’s up to client. And client is not answering for 2 days so far. You can use special subcolumn (as Pawel suggested), or you can move your item back – which is hard. If you put it in the “on hold” column you encounter the problem with moving item back once again. I hope this example helps.
Joshua,
With features which are blocked or have to be redone I tend to keep cards where they are, so I have the same approach as you. For example we had a feature blocked for about two months and it was waiting there, in development column, being a real pain in the ass and a motivator to press on our subcontractor to solve it. It was an exception though.
Now the situation changes when it becomes a typical scenario, for some reasons you have features “blocked” on a regular basis so they stack up. Then you can either make your limits loose, allow to break them often or change the flow. As I don’t like first two solutions I choose the third.
And you’re right about one more thing – if the team needs rework of many features it doesn’t mean you should change the flow. You should probably find why you suck with designing/preparing features for development as this is the real issue.
And yes, it is different with features blocked by someone outside the team. You have no or very little control over unblocking features and it could happen they will be stacking up very fast. Then leaving things in the standard flow results in mess and doesn’t help in effective delivery.
William,
If you consider a situation where a feature can go back and forth between new (blocked) state and old (ongoing work) one you end up moving cards back. Imagine working on a bug submitted by the customer where you have a multiple iterations of checking fixes, asking for logs etc.
On the other hand it isn’t a normal state for each feature – you use it only when situation requires that.
Yes, you could add an additional column but then you complicate the standard flow, you risk moving cards back (which creates a mess) and you make it more difficult to define clear transition criteria. Priority queue is a neat solution to mimic that additional column.
“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.”
i don’t think this argument is enough not to move it into TO DO part. Just add additional description/clarification to the item
In todo column I expect features which are not work in progress and I don’t want to see this kind of feature there. I might put it back into the backlog, what I do on occasions with fetures in todo. And I want to see feature progress – if it made it through to testing I want to see there, not in todo.
But you’re right with one thing – there is no rule here. If putting features back into the backlog works for your team that’s great. I just found there’s too much mess attached to moving sticky notes back and I try to avoid that.
Very interesting thread, we have a card which is in a blocking state for the next 2 month (external constraint), should we remove the card from our kanban board ?
@fabrice – A short answer is: it depends.
Think about pros and cons of: keeping the card, removing it and finding some kind of waiting place for it.
In the first situation you have disturbance of the flow which on one hand makes things more difficult for the team but on the other it reminds you again and again to do anything you can to solve the issue, e.g. call the external entity to remind them how important it is for you. And there’s one more thing here: you can be sure that eventually a feature will be completed and you won’t be left with a piece of trash (unfinished and not working feature) in your code base.
The second option means getting the flow back to normal, but at risk of forgetting of the issue and an unfinished feature at all. As unlikely as it may seem, the moment you remove the feature from your visible range is the moment you stop reminding yourself about it and eventually you may stop thinking about it at all. By the way: it was my huge discovery the first time we started working with Kanban: we had many such forgotten features just after a few months of development. I was surprised how many of them we had.
The third option is sort of compromise. You clear the flow but still find a special place for the feature so you don’t forget.
Either way, you should start answering the question: do you still want to build this one. If so, look for a method to keep it. If not, look for a method to clean your code base and throw the feature out. I mean, removing unused code can be a perfect way of completing this feature in this specific case. I’ve done that on a couple of occasions.