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.
