Kanban at White Label Dating

Written by Keith McDonnell. Last updated on Sunday, January 17, 2010.

The team was in trouble! We’d been managing the project for the previous four months using Scrum. Then, with four weeks to deadline, it turns out we had a stealtholder, ie someone who had the authority to radically change our release plan.

OK, we have a number of new features and a new product owner. What to do?

I’d been reading about Kanban for some time and it seemed to fit the bill. It’s less perscritive than Scrum and could fit into our new workflow.

What is Kanban ?

Kanban (Japanese for card board) is one part of the Toyota production system .

Adapted for software, it boils down to three practices:

  1. Visualise your workflow
  2. Limit your work in progress
  3. Calculate your cycle time

The idea is to track a piece of work from its inception to monetisation. In our case from an idea from the marketing department to measured ROI based on metrics and customer feedback.

Visualise workflow

Very much like Alistair Cockburn’s information radiator , the Kanban board should be:

We took a poster and drew vertical columns for each of our workflow states: Backlog => Next => Development => Code reviewed => Biz acceptance => Done . Very similar to Henrik Kniberg’s example board:

Limit work in progress

We placed a limits on each workflow state to

The pull system really is the key to the process in my opionion. How it works in practice is, eg if there is are no work in the backlog or next, a developer should go and fill the queue with work from the product owner, marketing department whoever. It is this culture of self organisation and responsibilty that I like most about Kanban.

Calculate cycle time

This one is both really easy and really hard. Keeping track of how long it takes to do a piece of work should be straightforward – right? Wrong! All pieces of work are not the same; some require the whole team, some require copy from the marketing team. We resolved these problems using story points and velocity.

Story points are estimates of a stories complexity or size. We used a scale of 1 – 5; 1 being easy & straightforward, 5 begin a serious piece of archictecture.

To calculate the team velocity, I simply totalled the story points for all of the stories complete that week. I then updated our burndown graph.


Kanban is easily my favourite software development process, lightweight and powerful. Needless to say we used a grab bag of tools from XP and Scrum, such as:

One more thing: the more visuslasation you can put on your Kanban board, the better. South park avatars of your dev team, screen shots of the app, colorised cards, burndown graphs to name a few make a huge difference to the team dynamic. And oh yeah – have FUN with it!

Further reading

If you'd like to discuss this article, you can send me an email keith@dancingtext.com and/or publish an article online and link back to this page.