Our kanban story card

Dale Humby bio photo By Dale Humby
One of my primary inspirations for the switch to Kanban for product development was David Anderson's Kanban book. But in the Kindle edition the photographs and diagrams are so blurred that it's often difficult to figure out what he's describing. (To all Kindle authors: Please use vector graphics and high quality photographs. Please!)

Without tangible examples we had to discover the best way to lay-out our Kanban board and write-up story cards for ourselves and I think that's still the best way. But I hope our experience can inspire someone else.



The card layout

At top left is class of service. This story had a Fixed Delivery Date, FDD of Monday, 9 April. (As you can see we missed that date...) During planning we write the due date and can track our performance as the story moves down the Fixed Delivery Date swim lane.

The majority of the card it taken up by the story. We use style of "As a stakeholder, I want feature, so that goal." (A possibly better way to write stories is "In order to goal, stakeholder needs feature" because it puts the goal first, not last. I'll try find the reference.)

On the right hand side are the dates the story hit each of the stages in our delivery pipeline.

During the daily stand-up, for each day the story has been in progress it gets a dot. A green one if it's within the 5 day SLA, thereafter a red dot.

At the bottom left of the card we record the number of tasks written up during the stories planning session (5), tasks that we didn't think of during planning but had to do anyway (2), bugs and blockers (both 0.) I have been tracking these numbers and although I haven't formally analysed the data yet there is a definite trend between number of planned tasks and how long it takes a story to get through development. Basically, if during planning a story has more than about five tasks the dev team discusses splitting the story because it stands a good chance of missing our five day SLA. Retrospectively, we can determine how good our planning was based on the number of unplanned tasks a story had.

David Anderson suggests using sticky notes for stories and referencing them back to a bug tracking system. Most of our teams work is new features or bugs they file themselves. We haven't got to the complexity where we need software bug and feature tracking yet. So we wanted larger story cards, and use sticky notes for direct development task tracking. Our tasks take at most half a day for a pair of developers to complete, and the sticky notes get binned as soon as the story moves in to Demo or UAT. The developers mostly use them to record decisions made at the planning session for that story.

Curing the pox

I want to go back to the green and red dots for a minute. For the first month or so we didn't have a good way of visualising how long we had been working on a story. One could read the dates on the card but it was an effort to work out the number of days a story had been in progress taking in to account the weekends.

At that time we also had our WIP limits too high, and even then busted the limits more often than not. Delivery was slow and just about every story missed it's SLA. 

Lack of progress visualisation on the story level nearly caused us to go back to Scrum with it's simple, weekly burndown chart. 

But one of our developers came up with the idea of placing coloured dots on the cards, green when in SLA, red when out. He did this for each story that was in progress and called the dev team over to view his work. They were mortified- some cards had so many red dots that just about the entire front was covered. The wall was so full of red dots that it hurt to look at for more than a few seconds. Not only that, but our kanban wall is in a very public area of the office, so our red-dotted SLA-misses are very public and embarrassing. 

Over the next few days the team released the stories that had been languishing in UAT and Ready for Release, in turn reducing our WIP. 

This simple method helps answer the developers question, "What am I going to work on next?" They can go to the board and pick the story that's been in progress the longest and try and get it released. Picking the oldest story also encourages developers to pull work through the pipeline from right to left because the oldest stories will generally be toward the end of the pipeline.

Every time we increase visibility, whether of impediments, work in progress or time in development (as in this case) we see real productivity increases.