TL;DR
Your process may be missing some intermediate queues in your work-flow, making estimates harder than they need to be. You may also need to work more closely with your stakeholders to decompose epics in order to provide meaningful estimates. And finally, you may need to provide your team and organization with more education about how estimates are performed in Kanban.
What Kanban Measures
Kanban measures a number of things very well. Some of the metrics Kanban helps teams measure include:
- System throughput.
- Process cycle time.
- Average and optimal batch sizes.
Kanban works most efficiently when you have a consistent batch size because that optimizes system flow. High variability in the average size of your user stories will lead to unpredictability in the cadence of the iterations, making accurate estimation more difficult.
Optimizing Estimates for Flow
In Kanban, scheduling estimates are typically based on two things:
- How long it takes an average user story to be pulled through the system.
- How many stories, on average, can be pulled through the system in a given time period.
Scrum provides explicit, fixed time-boxes into which work is scheduled. In contrast, Kanban provides continuous flow from input queues to output queues; there are no fixed time-boxes as such. This requires a slightly different world-view when providing estimates for specific features.
Kanban Estimates in BDD Style
So, if it were my team, I would provide the estimate in BDD style, making the calculations and assumptions explicit. For example:
Given an average backlog of 20 items
And an average story size of 2 story points
And an average system throughput of 8 story points per week,
When asked for an estimate of how long it will take to complete a 21st story
Then the team would estimate that the story can be completed within three weeks.
Your Process May be Missing Some Queues
User stories have a cycle time; epics don't, for the simple reason that epics are never pulled into the system as Work-in-Progress. It's fine to put epics onto a backlog, but you must decompose them before they reach the WIP stage.
It sounds like your current process is missing a couple of important queues. I would suggest this work-flow instead:
Backlog -> Analysis/Decomposition Queue -> Ready Queue -> Development WIP -> Test WIP -> Completed Work
Apply some sensible queue limits to the Analysis and Ready queues, so that you don't pull more from the backlog than you need. Respect your global WIP limits, but keep in mind that limits can be applied to columns and swim-lanes on your board, too.
