I am aware that Cumulative Flow Diagrams are the norm for a Kanban / swimlane-style system, but I found I derived no useful information from them. I was hoping to see some patterns evolving, but I wasn't getting any more information than I was watching cards flow along the board. I would hope it would red-flag places where bottlenecks were occurring and give me clues where I could be optimising the system.

Are there other charts or graphs that are employed for Kanban system that work really well to highlight issues?

3 Answers 3


In Kanban you get most information from the board itself and data you can scrap from it. CFD can also deliver some useful information. Usually the board + some data analysis (Excel sheet) + CFD is enough to get all the information you need.

  1. The Kanban board

    One thing you mention are bottlenecks. You should find them easily on the board. As a rule of thumb - if you keep hitting limits on the board it probably means you either set your limits too tight or there's something wrong with the way people work, e.g. they start too many new tasks without finishing the old ones.

    Another thing are tasks which have been hanging on the board too long. If you write down starting date on a sticky note you can easily see how long the task is under development. Then it takes a quick analysis to decide whether there is some problem with the task or simply it was too big, and you should have split it to a few other at the beginning.

    Then you have blockers. The easiest trick to make them visible is to mark cards which are blocked with some visual, e.g. small sticky note. With this approach you should instantly see how many tasks are blocked at the moment.

    Also you can mark who is working on the task at the moment, e.g. with color pins or color magnets, which gives you a clue who may be possibly overwhelmed with tasks.

    If you use priority lane you can note whether there is some emergency down the line. It is when there is anything on the priority lane.

  2. Data from the board

    Another useful thing which isn't instantly visible on the board is the information about estimates and real development times. If you want to use estimates (many Kanban teams don't) put them on cards. Then note starting time and ending time to get how much time it really took. Then it's enough to put the data into an Excel sheet and you can build over that pretty good estimates to new systems when you need them.

    Also you can measure team throughput, e.g. how many features team can complete in given time.

    You can learn how the team become more fluent (if they do) and how you get better at splitting tasks from the sheet as well. It's enough to check how cycle time changed over time and analyze specific cases, e.g. we came from 30 to 12 days in cycle time but the main reasons was we started splitting work to smaller features and not because we got that better in finishing fast.

  3. Cumulative Flow Diagram

    Cumulative Flow Diagram can be very useful as long as you know how to read it. CFD shows how cycle/lead has improved over time, how big backlog has been over time, how often we release new versions etc.

    CFD doesn't show specific numbers, Excel sheet works way better here, but is way more useful to show trends, e.g. cycle time becomes shorter, we keep release frequency at stable rate and our backlog is at steady size since we're constantly getting new features to build.

    A longer description of how CFD works and what kind of interesting stuff we can learn from it can be found here.

    And here's a Paul Klipp's picture which describes what you can see on CFD: Paul Klipp's picture of Kanban CFD

  • Comprehensive answer Pavel, thanks. I do all pretty much all those things you recommend except we don't estimate task duration. I have been making a note of task entry and exit dates but yet to run analysis on them. The link to the image is very useful but I still find reading the CFD unintuitive.
    – Gary
    Commented Feb 24, 2011 at 13:17
  • I find Excel sheet more useful to find specific data, e.g. how long it typically takes to complete a feature, and CFD (which I don't use very often) to show trends, e.g. how do we improving cycle time over time. However it's hard to discuss CFD in general - it works much better when you're familiar with the example. Commented Feb 24, 2011 at 13:45

I would add the following to Pawel's answer (which is great):

Use Control Charts when looking at data - for example for Throughput and Cycle Time variation. Chart each story that finishes with the related Cycle Time it exhibited. This will show you Average, variation, add 2-Sigma control limits (easily created in Excel using trend/error lines), and you can derive possible SLA, exceptions for Kaizen moments. This is dealing with Special Cause Variation. With time, aim at improving your average. Same can be done for Weekly Throughput - look for weeks with exceptional performance (good or bad) and think what caused it and how to create more great weeks and less bad weeks.

Buffer Management - inspired by TOC sDBR - using the Cycle Time history/SLA, when adding a card to the board, calculate when is the worst case scenario for when it should be done. now you can look at the board, and assign "colors"/"status" to cards according to the time left on their clock. e.g. if average cycle time is 7 and worst case is 14, use an SLA of 14, and start cards when you have 14 days until due date (if due date is relevant).

now, once you start, card should be green with 5-14 days remaining. yellow with 3-6 days remaining - warning sign to start doing something about it red with 0-3 you really need to scramble and finish this card black - this should have been finished by now. This provides you both with the ability to manage priorities, as well as retrospect after the fact - those reds/blacks are interesting to look at...

Another interesting area is blockers - once you find an item is blocked, mark that as a new card, with the date the blocker was created. when removed, mark the day it was removed. Then do a control chart, and also track the blocker reasons and look for trends...

There are more metrics/charts you can use - some people liked some presentations I did on the subject:

  • This colour / status idea is quite interesting. It's not relevant to my current implementation but I will keep it in mind for a future project. Thanks!
    – Gary
    Commented Feb 28, 2011 at 14:06
  • I recently started measuring my scrum team's velocity on a control chart. eye opening in terms of how consistent our estimation is. Highly recommended.
    – Ben
    Commented May 24, 2011 at 22:16

One of the most useful chart for me is % complete over time. I measure the % complete in terms of estimates on the y-axis and time on the x-axis. It's not necessary to take a reading every day

With this chart, it's fairly easy to project out to a completion date. One difficulty with the cumulative flow diagram is that with story growth and completion rate both changing, it can be hard to pick when they converge on a ship date. With a % complete burn-up chart, both of these are accounted for in a single line.

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.