Comments on: Designing a kanban board – not as simple as you might think

By: Adam Shone

Adam Shone — Mon, 11 Oct 2010 10:28:09 +0000

Yes, we struggled a bit with this because if the tasks going through the kanban board are not relatively similar in size it reduces the value of the metrics you get out of it. We might, for example, have a simple one line change to some documentation and a hefty 10 day user story going through the same board. In that case is the estimated transit time per task actually useful?

One approach we tried to mitigate this problem was to package up simple changes into baskets of changes, so that if a quick update had to be made to a document then the developer would also look for other fixes/enhancement requests for that document in order to bulk up the task. That had the benefit of making our tasks more consistent in size, increasing the accuracy of the metrics, but with the trade off that developers were spending time working on tasks that, strictly speaking, didn’t need to be done at that point. Which isn’t ideal!

It’s definitely an interesting problem and I’d be interested to hear other approaches to deal with it.

By: Ronald

Ronald — Sun, 10 Oct 2010 13:10:52 +0000

There is an interesting point concerning “User Stories” / “Simple Bugfixes”. Our team uses redmine (ticket system with configurable workflow) intensively. We have made the experience that every artifact from big chunks like ideas or user stories to fine-grain tasks like small feature requests or bug fixes is wrapped in a ticket and treated in the same way. Maybe this is wrong. It might make sense to treat them in a different way, with different workflows, maybe even in different systems…

By: Martin Tyler

Martin Tyler — Wed, 17 Feb 2010 15:10:06 +0000

That would only work if you only have one ‘kind’ of resource, eg developers.. if you have developers and testers and whoever else you need states between these parts of the process

By: james peckham

james peckham — Wed, 17 Feb 2010 14:08:45 +0000

so wouldn’t a ‘pure’ kanban board just be not started, in progress, and done? Don’t take this offensively, i just want to know: what’s the purpose of the other columns? When would you actually use them?

By: Sarah

Sarah — Wed, 17 Feb 2010 12:03:59 +0000

Yep, I had the chat with David Anderson (Thought Leader of Kanban Systems) and I asked the question about Joseph Pelrine statement of creating an environment for teams to become self-organising, Pelrine states that you need to “turn-up the heat” within the team (not quite chaos but close) to see the team burst into energy and start self-organising, with scrum this is achieved by the timebox cycles. His presentation can be found here http://www.infoq.com/presentations/coaching-self-org-teams. So I asked the question to David Anderson how this is achieved with Kanban because Kanban leads to a calm steady flow through the system. He said use WIP limits to have the same affect of “turning up the heat” but if you are new to Kanban start working without these to map how you are currently working before making lean changes through WIP limits.

This was at SkillsMatter Lean and Kanban eXchange last December http://skillsmatter.com/event/agile-scrum/lean-kanban-exchange

By: Ian Alderson

Ian Alderson — Wed, 17 Feb 2010 10:32:50 +0000

Hi Joshua,

Adam isn’t in the office at the moment, however I believe that I can answer your question. The team didn’t have any WiP limits, although we have used them previously. The reason that we didn’t was because we were trying to determine where our natural bottlenecks were, which would then allow us to work out what the limits should be in the future. This was based on a suggestion from David Anderson after a conversation one of my colleagues had with him about Kanban at a conference.

By: Joshua Lewis

Joshua Lewis — Wed, 17 Feb 2010 08:41:19 +0000

Out of interest, did you have WiP limits for each column?

By: Duncan

Duncan — Tue, 16 Feb 2010 21:47:51 +0000

mmm maybe we should try taking kanban boards into a contextual study and map the workflow onto it… The rationale behind contextual studies is that people can’t ‘tell’ you what they do, as a lot of the time the steps are done without having to think about them.

It’s not so much working with your eyes closed, more… that as you become ‘expert’ you enter a work ‘flow’ state and can work without having to think about HOW you are doing, but concentrate on WHAT you are doing.