How to include estimating and its effect on prioritization with Kanban?

Question

I've read in several sources about Kanban. Using Atlassian's description as my current main source of information about how it works, I wonder how the effects of estimations on prioritization should be included in the flow.

Mentioned description suggest a Kanban board with these lanes:

1. To do
2. In progress
3. Ready for review
4. Done

The Product Owner then makes sure everything in lane 1 is prioritized. However, priority often depends on estimated effort (something might get higher prio if a quick fix is available, pushed back if it turns out to be a lot of work, etc), and estimating (a) takes time and (b) is best done by those that'll be doing the work.

I'm familiar with Scrum, where the team sits down to estimate on set times. There is no such thing with Kanban it seems. How would this typically work? I can see several options:

• The PO guesses, and the team learns to give feedback if the guesses are off;
• Introduce a "Lane 0" with "To Estimate" items;
• The PO mixes estimating him/herself and interrupting a team member's work to get an estimate;
• Introduce fixed moments for estimations (e.g. 0900 and 1300 hours);

I've searched and found some opinions like this one ("estimation is optional"), but am curious if there's any canonical advice at all?

Answer 1

One of the things Agile tries to achieve is the concept of 'doing it trumps talking about doing it', estimating is one of these things where you spend too much time worrying about how long it'd take you to do something if you eventually got on and did it. And generally, whatever estimate you come up with, you're wrong regardless!

So scrap estimates.

Kanban can tell you the cycle time for the tasks you put through it, and you can plot them on a graph to get a distribution curve of times actually taken (ie from when the ticket was placed on the board in progress to when it was removed).

Dennis Stevens suggests t-shirt sizing your tasks to get an understanding of whether to perform the or not, but t-shirting is a 10 second task in most cases - if I ask you how big a task is, you'll be able to say "trivial", "about average" or "mhmhmhmhhh.. that's gonna cost you g'vnor". Waste about that long on this kind of process, and then get on with working those tasks. Do not try to estimate every task, just those you're concerned about.

With Kanban I think the canonical answer is this: don't bother with estimates.

For prioritisation, there is a concept in Kanban called Classes of Service that you can use for those tasks you want to alter the prioritisation for - if something is not a priority (a task that is lengthy-but-important is still important, a task that is quick-but-unimportant is still unimportant after all) you can put it in as a slow-burn or intangible task that will be done after all the higher-priority tasks are complete and someone has time to devote to the task.

Answer 2

Your team should be doing regular Backlog refinement regardless of whether you're doing kanban or scrum. This will include the team providing some level of estimate. Try for relative sizing (fibonacci values) at first to provide enough information for the Product Owner to prioritize without spending too much time on the estimate.

Once the PO has estimates, take a look at Weighted Shortest Job First to help prioritize. This method should take some of the guess-work out of the prioritization.