The Problem

I want to have a relatively easy way to estimate how long a large feature is going to take to do. In Kanban, how can you plan work 2-3 months out without wasting too much time breaking down stories?

In Kanban, I could:

  1. Count the number of work items needed to do the large feature, say 50
  2. Determine my Work Completion Rate (say 9 items in 7 days = 7/9, or .77)
  3. Divide the number of items by the Work Completion Rate, 50 / .77, and decide it would take 65 days to do the feature.

Great. I'm happy, my stakeholders are happy, everyone's happy

Except: It's a major pain in the butt to flesh out individual work items for 65 days worth of work. The effort would also be a waste because some items would change as we learned more

Is There a better way?


In Scrum, I never had a problem doing this because I would use the Iceberg Method to do long-term planning. The gist is that I would assign large point values to big Stories. I wouldn't have to put much effort into them, just enough to compare the total number of story points for a release so I could take a guess at how many sprints it would take to do the work.

Unfortunately, if I'm using a work item's completion rate to do my 2-3 month planning, I'd have to break everything up.

Some Thoughts

  • If I decided to assign story points to the work items in my backlog, and tracked my story-point completion rate, then I'd be able to stick to my old ways of assigning big numbers to work items that haven't been broken down.
    • The Drawback to this is I have to go back to estimating work items again, something I was hoping I didn't have to do with Kanban (because all the stories would be roughly the same size).

Any insights to how to tackle planning 2-3 months ahead in Kanban without having to breakdown the stories into equal sizes would be greatly appreciated


1 Answers

Daniel On

The short version: This is not a problem that Kanban tries to solve. Information that you get from using Kanban can help in solving this problem, but Kanban does not really try to address long-term feature planning.

What it Does

One thing Kanban does is give you average lead times and cycle times. From here, I know that most items take X amount of time. I can either break items down into similar-sized items or I can look at the average time for S, M, and L items and use that to approximate the completion date of a body of work. In the past, I have used this same approach on full features instead of chunked-up backlog items to do portfolio planning.

It is worth noting that Kanban is a way to take a process and optimize it. Because of this, it does not tell you how to do things like plan and estimate. It is often subject to the same strength and weaknesses of the process you are applying it to.