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:
- Count the number of work items needed to do the large feature, say 50
- Determine my Work Completion Rate (say 9 items in 7 days = 7/9, or .77)
- 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.
- 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