Zsolt Fabók

Practical ideas on kanban, lean, scrum, xp, java, programming…

Internal Done Columns

in kanban

If a team uses a whiteboard to visualize the workflow, it is quite certain that the team has a Done column. The finished user stories, tasks, cards, etc. end up in this particular column. It is usually the rightmost column on the whiteboards. This year I realized that it is not enough to have a Done column only at the end of the whole value stream, but it is good to have one after each phase. In this post, I’m referring to these columns as internal done columns. They can have different names like finished, ready for…, but they serve the same purpose: to make it visible that an item is finished and can be continued in the next phase of the value stream. A whiteboard with internal done columns:

Let’s examine the usefulness of the column from different perspectives. The internal done column is the right part of a phase column, where the team members can put their finished items. It helps to make a so called ”pull system” continuous. In a pull system, we have the puller, who has finished his current items, and is now looking for new items to work on, and we have the pusher, who is working on a certain piece at the moment. In this example, the puller cannot contribute to the ongoing items, that’s why he needs to pull a finished item. For example, he is an integration tester who shouldn’t contribute to programming items.

If the team has a whiteboard as above, it is very hard to determine which item is finished and can be moved from left to right – in other words: can be worked on again. If an item has no avatar or blocking sign over it, one can assume that because nobody seems to be working on it, the item is finished. In fact, it may be finished, but it can also be blocked, or abandoned as well  due to some other higher priority issues. In order to confirm the actual status of the item, questions need to be asked, which interrupts the current work. It is a fair question from the puller, though: Which item can I start working on? In order to answer it, the puller must interrupt almost everybody from the whole team in order to get an answer. Raising questions and talking to colleagues is good, but in this case, this question makes an unnecessary interruption which needs to be avoided. A worse example is when the puller waits for the daily gathering (daily scrum or stand-up meeting) to know which item can be worked on.

If there is an internal done column for items, the puller knows exactly which item can be taken.

The pusher has less to do with this column, but from a psychological perspective, it feels good to finish something. If someone works on a particular item and it is finished, it feels good to move it from left to right even if the destination is an internal done column.

How the team places the items is important. Do not have ongoing and done items next to each other, because they can be easily spotted as one item, and if someone misses this and puts and additional item in the column, there goes the WIP limit.

I observed our teams, and learnt that sometimes (2 out of 5 times) it was hard for them to recognize that the column above has 3 items, not 2. If the column had a WIP limit over 10, it would be even harder.

Other important aspect is the prioritization of items. Always prioritize the done items higher than the ongoing ones. In a pull system – such as Kanban -, it is important to finish something, then move forward the ongoing items simultaneously.

In the column above, it is more important to finish items ‘D‘ and ‘F‘ than to help the others to finish item ‘C‘.

It may ruin the symmetry or may make the whiteboard inconsistent, but do not have an internal done column for the last phase. Imagine that you have two done columns – the internal and the rightmost Done. How can people decide which column they should put the finished items in? Based on my experiment I did a couple weeks back, it really confuses them. The last column has a WIP limit, and if it is filled with done items, the whole stream is blocked unnecessarily with finished items. Until the board is not reviewed and the done items are not removed, it remains blocked. This requires an unnecessary gathering.

Of course, if the internal done column does not fit into the current whiteboard or into the team’s system, there are other things they can do:

  • Aligning the items: align the ongoing items left and the done items right (figure on the left)

  • Put the finished item on the line between the phases (figure on the right)

These are the things I observed and learnt about done columns in the last year. Maybe it seems to be a minor issue, but in retrospect it helped us go a bit faster, and helped us be more transparent.

Related posts you may find also interesting:

Comments