Archive for August, 2011

Kanban is not go horse!

August 29, 2011

Many people new to Kanban think it is a “go horse” method: one that you do whatever you want, without any planning, nor cadence, nor predictability. Those people couldn’t be more wrong! There are four practices that are mandatory in Kanban:


You must visualize your work and how you work, so that you can understand it and improve it. The most common method for visualization is a wall board with a map of all the states that your work items must pass, from concept to delivery.


You must measure and optimize your cycle time (or flow), which is the average time needed for a work item to go from your first state to your end state.

WIP limits

You must limit how much work can be at each state at any moment, so that you can improve your process, know your capacity and shorten your cycle time.

Explicit transition policies

You must define explicit transition policies between ALL your states. This ensures that everybody is following the same rules, thus making your process very clear and repeatable by everyone. Those policies include the famous “ready” and “done” policies from Scrum, as they usually map to the first and end transitions on a typical Kanban board.


So you cannot do whatever you want, because you have very explicit rules. You can have as many states as you see fit, so you can have a “planning” state, also. By measuring and optimizing your flow, you have cadence and predictability. So, no, Kanban is not go horse!


Workflow mapping to a Kanban board: state, queue or transition rule?

August 26, 2011

A common question that arises once you start implementing Kanban is whether a step of your workflow should be mapped to a Kanban board state, queue or a transition rule between two states. My approach to this question has been this:


If your work item will usually be in that workflow step for at least an entire day, with some tasks going on until it can be considered ready to move on, then this workflow step should be mapped to a Kanban board state.


If your work item will usually be in that workflow step for at least an entire day, but without any task going on, then this workflow step should be mapped to a Kanban board queue, which is a buffer to your next state so that you can smooth your work items’ flow.

Transition rule

If your work item will usually be in that workflow step for just a couple of hours, this is a very good sign that maybe this workflow step should be mapped to a transition rule between two states of your Kanban board. Our teams usually create one task for each transition rule, in addition to the other tasks needed to consider a work item ready to move on, so that they ensure that no rule will be forgotten.


It is important to have in mind that you can always change things until you find the best format for your Kanban board. You can always start with a workflow step mapped to a Kanban state and after a week or two you can try to transform that state in a transition rule, to test which configuration works better for your team.

What do you think? Does it make sense?

Experimenting with Kanban: keeping track of a roadmap

August 17, 2011

One common question that arises when we start a Kanban implementation is if we won’t lose track of the macro roadmap of our product due to Kanban’s continuous flow. It’s generally accepted that Scrum forces the Product Owners to plan some sprints ahead and also to have a release plan for his product, while Kanban don’t prescribe sprints nor release plans. Well, the answer to this question is: yes and no.

Yes, we can lose track of the macro roadmap of our product due to Kanban’s continuous flow, because Kanban offers this degree of freedom. It’s also this freedom that enables Kanban to be used in a lot of contexts, like the one of infrastructure teams, where they don’t have a roadmap to follow, but mostly incidents to solve.

And no, we can still keep track of the macro roadmap of our product using Kanban with two different approaches. The first one is by forcing the Kanban work items to be features, or better yet, MMFs, instead of small tasks, so that our entrance queue becomes a roadmap. We can also control the size of our entrance queue with a max limit and we can have a rule stating that we should not have less than N features on it at any time. This will force a roadmap and yes, you will still be doing Kanban. Another approach is to use Kanban with iterations, instead of continuous flow, thus forcing the planning of your iterations and maybe forcing a release plan, too. And yes, Kanban don’t prescribes continuous flow, too!

Doing Kanban with iterations is usually called Scrumban. 😉

Focusing on product advancement instead of the development team performance

August 9, 2011

Even though cycle time is a good metric about team’s peformance, as I described in my previous post, all stories and features that a team is delivering should be validated by the Product Owner (or Product Owner team) once they are in production. This validation should check if the stories and features just delivered made the product advance in the way it was expected.

But what is this product advancement thing? Well, it depends on your product’s context. Better yet: it depends on your key performance indicators (a.k.a. KPIs). A product is advancing if it is improving its KPIs. As an example, if your KPIs are pageviews and number of subscribers, then your product advanced only if the delivered stories and features increased your pageviews and number of subscribers. This post describes a very good way to define your KPIs. This book is also a very good reading about how to define your product’s advancement metrics.

My point is that many companies are more concerned with their teams’ capacity: how many story points a team can deliver or how long is a team’s cycle time. But they should be more concerned with their products’ advancement! A team’s capacity is only a mean for achieving something greater: product advancement. And product advancement is achieved only if the right stories and features are being prioritized.

What do you think? Makes sense?

Experimenting with Kanban: the cycle time metric

August 2, 2011

If there is a Kanban practice that keeps surprising me again and again is the cycle time metric measurement and optimization. We defined cycle time as the average time that a story takes from our first state (backlog) to our last state (production). It tells us how much time our team takes to finish a story, on average.

Compared with the velocity metric that most Scrum teams uses, cycle time proved to be more accurate for planning and simpler to comprehend. It is more accurate because it is something that we are measuring and not something that we are guessing. And it is simpler to comprehend because its measurement unit is time and not points. While time is something that we have been dealing with since we were born, points are an artificial unit created to simplify software estimation, which is a very complex task by itself. So, instead of guessing how many points each story costs and then taking as much as the team guesses it can handle in a sprint, we know that the team finishes one story every X days, on average, and that N stories will take them (N * X) days to finish, on average. Much simpler!

My first surprise was when I saw the number of stories one team was refusing after we started to measure cycle time. When I asked them why they were refusing those stories they told me that they were refusing them because those stories were missing some important pre-requisites. Those pre-requisites included: other team’s components readiness in our integration environment, infra-structure, definitions etc. Without those pre-requisites they were likely to come to a halt during development, what would affect their cycle time directly! WOW! Very nice! For the first time, the team became aware of the importance of their definition of ready! And they were fighting for it, now! Amazing!!

Another great surprise was how the team became concerned with their cycle time to the point that they decided to print their cycle time evolution graph and put it on the wall, above their kanban board, so that they could always track it and discuss actions to improve it during their daily checkpoints. This behavior answered a concern that I had since the beginning of our kanban implementation: couldn’t the team become slower without the sprint’s timeboxes? And today I can tell you for sure: NO! The answer is: cycle time. 😉