Kanban Board

On the project I am currently working on we recently decided to adapt the SCRUM process to include some LEAN flavoured sauce.

Specifically we found the way we were running sprints was not working for us. We are in a period in the UK where lots of people take their annual holidays, as a consequence of this we have project members dropping in and out of the project. Planning sprints using previous velocity had become a bit more complex than it should be; so we decided to not decide up front what our sprint would deliver.

We wanted to start each sprint with just one story per developer, so they had initial work to do, and no more. As each developer finished a story they could pull a new one into the sprint. We recognised that we would need to impose Work In Progress (WIP) limits to eliminate waste. If a developer found they had finished a story but the WIP limit had been hit, they would have to change hats and pull a story from the Developer done queue and into the Test queue AND test it.

We decided that a Kanban board would be the best way for us to visualize how the sprint was progressing. Here is our Kanban board.

KanbanBoard

The Backlog column represents all stories that could be worked on, these all having been ranked on priority by our customer.

The Selected column represents those stories which should next be pulled into the sprint.

The Developer column has been subdivided into ongoing and done, the jury is still out on these names effectively done here means in the test queue.

The Test column has also been subdivided into ongoing and done; done being a state the story is still in until it meets our Done, Done criteria.

Comments

# re: Kanban Board
Gravatar Hi Tom,

On thin you might consider changing is how you structure your WIP limits. Right now you have a limit on the Ongoing column and DOne queue, separately. however, the actual WIP limit for Dev in this case, is the combination of both columns, not an individual column.

Consider this: You have three items in your Dev / Done column, and you have three items in your Dev / Ongoing column. The three items in Dev / Ongoing are finished before any of the items in Dev / Done are pulled into Test. In this situation, you cannot place the finished items into the Dev / Done column because the limit has already been reached for that column. So, the finished items will sit in the Dev / Ongoing column even though they are done. This has effectively made the Dev / Ongoing column a queue for done items.

So, you should consider making the Development group of columns have a single WIP limit (maybe 3, maybe 4, maybe 6) and not distinguish between the Ongoing / Done column WIP limits because both of them are still WIP - one is just waiting for the next step.

other than that, i'd like to discuss your specific process and team needs in order to suggest any other changes. since each team's scenario is unique, you will likely end up with a unique Kanban system to represent it.
Left by Derick Bailey on 8/19/2009 5:45 PM
# re: Kanban Board
Gravatar Hi Derick,
Thanks very much for your feedback.
I see exactly what you mean about the sub-column based WIP limits. We did originally have one limit for the Dev column, but I convinced the team to change it, oh well ;-).

I agree with you about a unique kanban, in fact I don't really see how anyone can not have a unique one :-)

I'd love to chat with you in greater detail about what we are doing here, do you have a mechanism in mind?

Thanks again
Left by tquinn on 8/19/2009 10:45 PM
# re: Kanban Board
Gravatar feel free to email me anytime via email (firstname at firstnamelastname dot com) or Twitter (@derickbailey)

(i tried to send you my info via the Contact form, but it kept saying it couldn't send the message.)
Left by Derick Bailey on 8/20/2009 1:57 AM

Leave Your Comment

Title*
Name*
Email (never displayed)
 (will show your gravatar)
Url
Comment*

Please add 7 and 5 and type the answer here:

Preview Your Comment.