How do I track progress when using Kanban? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers. 开发者_开发技巧

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 3 years ago.

Improve this question

We are thinking of moving from Scrum to a more Kanban style of development, however one thing that is not clear to me is how to monitor progress under Kanban.

I have read that progress can be measured by monitoring the cycle time of each story and then presumeably applying this time to the number of outstanding stories. But this seems to me to be dependent on the size and complexity of the stories which could all be different.

I have also seen burndown charts being used, so would there be a chart for the entire release? As the backlog is not fixed (unlike during a sprint) would you just allow it to burn up/down as the pending backlog is amended by the PO? I guess as you get closer to release the backlog should be less volatile allowing you to burndown to completion.

After further thought I think my problem is that our managers like the 'illusion' of control that a burndown chart brings. They tend to see it (wrongly in my opinion) as a schedule and so are able to make judgements like the project is 'on schedule' or 'behind schedule' or whatever. I cant quite see how this is replicated in Kanban. Maybe thats a good thing.

---

For a whole project the best way to track progress is Cumulative Flow Diagram. Learn more about CFD from this presentation. You can also learn from CFD about things like bottlenecks etc.

For a specific tasks it really depends on your approach. If you have small features (like 1-2 days of development) on Kanban board you can see the status directly on the board since features are moving fast through the workflow.

If you use bigger features, you may want to split them into smaller tasks. This is basically how we work with our features: for bigger features (like 5-10-day long) we split them to development tasks (we don't put development task on the board though). Then I can say that task A has 3 out of 4 development tasks completed so we're doing well. Additionally we estimate the length of development tasks so I can distinguish between 1-hour long and 8-hour long tasks. For small features we have just a single development tasks which is developing the feature.