Archive for 2009/06/13

About kanban and estimations – just a clarification

I previously wrote a post about how we’re starting to implement kanban and I think there is room for some clarification about how we use our estimates.

What you need to keep in mind is that on top of our software development process, we have our project management process. This process raises the funds and priority for the project. When we implement a project, this affects the budget for different departments, based on the assumption that we save time or increase income. To give you a very basic principle, we can have a project which consists of two themes. So, we build a business case:

  Benefit department A Benefit department B Sum
Theme 1 500 100 600
Theme 2 100 300 400
  600 400 1000


In our business case, we should have a budget of at most 1000 to be able to break even. So, for simplicity sake only, lets say that we include resources matching 1000. The budget for department A & B will now be affected so A carries 60% of the costs and B 40%.

We start with Theme 1, since this has the highest priority. But we must not forget that we cannot continue with theme 1 during the whole project. If we would only deliver theme 1, department B would probably be disappointed. They got to carry 40% of a project which does not benefit them as much.

So, what I do with the estimates is just delivering this to the developers. They are made to understand about how much time will be spent on the different themes. But it’s important to stress that this does not affect the quality they will deliver. It just give them an idea on how big big part of their time should be spent on the different themes. This to enable them to deliver with quality. I see this as transparency in information between customers and developers.

This does not mean that the developers commit to an estimate and here I see the big difference with scrum. You cannot commit to deliver on an estimate. In most cases, things tend to take a little bit longer than expected. In some cases it takes shorter time. The important thing is that the team spend the right time on the right stuff to deliver the right quality.

So, how do I use the estimates? Well, I just keep the guys informed on how much of the budget on each theme that is spent and when we get near the end of the budget of theme 1, it becomes really important to finish the important things on that theme so that we don’t stand there and are faced with the options of delivering 1 with poor quality or 2 with too little effort.

In practice this means that when we’ve used 30% of our resources, I start to really stress completing the tasks, verifying with customers that they have the features they really need so that we can use the rest of the time just completing the work. By now, the guys think they are about 90% done, but means that half the work remains so now we should really avoid new features.

Categories: Agile, planning Tags: , ,