You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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)
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:
To quickly get you going, consider looking at:
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.