We are about to start working with Kanban instead of Scrum for our product development. We have identified that we will ahve the following flow:

Backlog -> Analyze -> Development - Test

Nothing strange there. For stories that are small from the beginning there is no problem. But what happens when we have epics and in Analyze split that story? Some sub-stories will move to the Development but some might go back to the backlog. How do we than measure lead-time when we are moving some stories forward and some backward?

Another dimenson of the problem is that different stories will have different size and we want to have small stories and than we break them down in small parts. But the stakeholder is more interested in lead-time for the whole story. He want to now that if his epic goes to the Analyze column, how long will it take before the whole epic is complete?

3 Answers 3



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:

  1. System throughput.
  2. Process cycle time.
  3. 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:

  1. How long it takes an average user story to be pulled through the system.
  2. 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.


Without a clear understanding of the epic acceptance criteria it would be very difficult to determine the completeness of it. Therefore, the first action after committing to develop the epic (the moment where you should begin to measure lead time) should be to define those criteria.

About the splitting issue, IME you can use some size estimations techiques to define a suitable range of actionable sizes within a defined timeframe (for an epic a maximun of a month should work). I used http://agileworks.blogspot.com/2008/01/team-estimation-game-by-steve-bockman.html?m=1 for portfolio slicing with success.


Here is an example of the the scaled agile framework portfolio kanban board as implemented in Leankit:

SAFee Portfolio Kanban

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.