Home > Agile, planning > Kanban & estimates

Kanban & estimates

Estimate or not? Using kanban is focusing on delivering completely done items and having as few items as possible in progress at one given moment. So, should you estimate?

When you discuss estimation, independent if you’re doing scrum or kanban, you have objectives (scrum term product backlog items). And to accomplish these, you have tasks leading up to the objectives. When using scrum, a relative value should be used for estimating the objectives (so called story points) while an absolute value is used for tasks. These are separate estimations which are also done during different occasions. You estimate product backlog items (or user stories) during release/product planning and you estimate tasks during sprint planning meetings.

Before you answer the question “estimate or not” you need to understand why you estimate and if that applies if you are using kanban instead of scrum.

The main reason for estimating user stories/product backlog items in scrum is to be able to plan your releases and to be able to prioritize. When you know the relative size of a story, you can more easily set a priority and if you know your velocity (the avergae number of story points completed during sprints) you can plan for approximate deliveries for your features.

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Do we still need to plan releases and prioritize? Well, yes you do. These needs remain, so I do think you should keep estimating your product backlog. You cannot use the same definition of velocity, since you don’t have the sprints but you can calculate velocity as story points/week or story points/months.

Do we need to estimate tasks then? Well, since you don’t have the committing to the sprint backlog, this need is actually not there anymore. But another need has arisen. You can in many cases put in everything from very little effort to a lot of effort into a task and before you get started, you need an indication of how much work is to be spent. But you don’t have to be as specific as in the case of scrum task estimating.

  1. 2009/06/08 at 3:50 pm

    I was under the impression in Kanban that estimates aren’t needed as much because items are supposed to be closer to being “of similar size”? Looking back to the original Toyota manufacturing process application, this would have been true.

    Otherwise, a large item might hang in your work queue for weeks (because it is too large) while small items fly through. If several large items “get stuck” then it might clog the whole kanban system.

    So… do you need to estimate to insure that items are small and closely equivalent? (maybe)

    • Anna Forss
      2009/06/09 at 4:37 pm

      Yes, that is very true: the effect when an item is too big is to split it (in two items or to one item with the unnecessary parts removed). I also need the estimates for our project methodology. Before starting a project, we calculate the business effects and we don’t want the costs to be higher than the effects.

  2. dpjoyce
    2009/06/09 at 1:48 pm

    I would point you to Corey Ladas article “Striking a different bargain with the business” for a different take.

    Kanban is *not* prescriptive, it does not say to estimate or not, as David Anderson says it depends on the risk and cost of delay.

    • Anna Forss
      2009/06/09 at 4:41 pm

      Thanks for the advice! Since I wrote the post I’ve realized (even more) that the reason for the estimates are not for the software development but for the project management. Project management should be a part of software development, but our organization is “not there yet” and is very much built on non agile values (read: hard core waterfall) and that is probably harder to change than the software development parts of the process. But I’m working on it. The reason for me moving to TUI was the opportunity to migrate to agile values. I thought that scrum would be the way to go but I’m leaning more towards kanban. So, I’m really happy about your response

  3. Prasad
    2009/08/11 at 12:32 pm

    Hey Anna,
    Currently I am doing a PoC using Kanban. I am in a midway
    a) Kanban is less prescriptive- team need to be highly matured and experienced to adopt right engineering methods
    b)SLA’s and cycle time – WIP limit very difficult to put a number
    c) confusion with roles & responsibilities

  1. 2010/11/21 at 4:04 am
  2. 2012/08/22 at 3:09 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: