How to create burn-down charts for Kanban?

[Ashutosh Bhonsle]

I am rather new to Kanban, most of my work experience is in SCRUM (time boxed sprints).

I am just not able to visualise how a burn-down can be generated when there is no time boxed sprint, let part the plugin to be used.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Burn down is a Scrum function, Kanban does not gather the data you need to build a burn down because it doesn't have sprints (the "time box" you mention)

Kanban measures throughput, not sprint burn, but you can make an assumption on a Kanban board that enables something like burn-down.  The way to think of it is "every card is a unit of estimate".  When doing Agile at scale, this is used a *lot* - Scrum teams do estimates, Kanban teams do not, because you can treat every Kanban card for a team is a fixed number of story points.

So, the simple trick is to create a new Scrum board that looks at the same issues the Kanban board does, have your team-leads create sprints that the developers don't need to look at, and create an automation that puts 1 story point on every card when it is creared.  (or another number, depending on your analysis of throughput)

[Bill Sheboy]

Hi @Ashutosh Bhonsle -- Welcome to the Atlassian Community!

In addition to Nic's suggestions...

As you noted you are rather new to using Kanban methods, I recommend pausing to learn about it, and perhaps how it compares to applying the Scrum Framework.  Perhaps look at online sources and some book reading:

• info from Atlassian: https://www.atlassian.com/agile/kanban/kanban-vs-scrum
• books from David Anderson on Kanban
• books from Daniel Vacanti on measures, such as Actionable Agile Metrics for Predictability

To quickly get you going, consider looking at:

• confirm your team's definition of done, and how that would map to board exit policies;
• consider how the team "intakes" work and "selects" it for delivery;
• what type of work does the team have that is "urgent" that might disrupt flow;
• consider how to reduce and manage work in progress (WIP);
• review the Cumulative Flow Diagram rather than the burn charts; and
• review Cycle Time and Throughput rather than Velocity.

Kind regards,
Bill

[Randy O'Neal]

You don't want burndown charts.  As mentioned above, you want to focus on Throughput, Cycle Time, and watch your Control Chart.  You can still measure Velocity as well.  I'd strongly encourage you to move to measuring all of these in issue count rather than story points.

We just converted our entire organization to Kanban; my two teams were the first to make the jump to Kanban.  We measure cycle time from the moment an issue goes into progress until it is accepted.

Stonikbyte offers several gadgets which we leverage to manage throughput, WIP, and cycle time; we also monitor velocity, but it's such a trailing indicator that I far prefer to manage to the first three.  The control chart is similar; it's a trailing indicator showing you where you had problems... which you already knew about because you were managing to throughput, WIP, and cycle time.

We do our best to "right-size" our stories by grooming them to be "complete-able within 3 days or less".  This doesn't always work out, but we strive to this goal.

The Product Owner has the toughest job in Kanban, in that everything has to be in current priority order... and that can and does change on a daily basis.

It can be a rocky start, but I'm a firm believer that Kanban is the natural "next step" in Agile from Scrum.  Some teams never grow past Scrum, and I think that's OK... but the next faster system seems to be Kanban.  I've believed this since 2014 and have been advocating for this ever since... and only this year have we been able to make the change... and I believe it is paying off in spades.

Good luck!

[Bhagat Singh]

How?

[Nic Brough -Adaptavist-]

Please see the answers already given