Hello,
I am managing an IT project in Kanban board, I have to report to leadership on the progress on the project. Can anyone suggest what are different ways to report metrics ?
Thanks in Advance.
Rajni Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
First of all, my recommendation, just in case you do not do that, is taken a look to Kanban method, the whole method, where the Kanban board is a tool but there are things associated to the tool like WIP. On the other side, we are using Kanban boards and we are using MS Azure DevOps as the tool to report metrics. You can take a look to Microsoft site and you will find good examples there. At the end, dashboards and artifacts are well known artifacts. With all that said, The point here is to understand the reason why you are using Kanban boards. For example, if you are using it to visualize flow of work while you are using Scrum framework then the way you report progress is based on sprints and features or user stories into each state inside the spint. Or, some people use to split stories into tasks then they report on task (which is a mistake in my personal opinion). Saving Changes...
If you are referring to "true" Kanban (as opposed to just using the term as an alternative for a work board or Scrum board), then there are a number of well defined flow metrics which you can review from either prokanban.org or by picking up a good reference on the Kanban method (e.g. David Anderson's Kanban).
One of the tools I use is a cumulative flow diagram. Using this diagram, I can show, over time, the work performed the work in progress, and the volume of work that remains. Battery charts work for a snapshot, but they don't show change over time. Saving Changes...
Again, if this is "true" Kanban and not just calling a work board a Kanban board, you might consider watching some of Daniel Vicanti's YouTube channel "Drunk Agile" videos as he focuses heavily on Kanban.
Aaron - it's interesting that Daniel is not a fan of CFDs. He had almost a full episode dedicated to that. Here are a few of the takeaways I got:
- You cannot tell where bottlenecks are and you shouldn't reflect backlogs in CFDs. The latter is because a CFD should represent arrival into the process and items in a backlog have not arrived in your process. Similarly, a CFD can't be used to show lead time, only cycle time.
- CFDs should not be based on work items (i.e. JIRA does it wrong)
- CFDs can show approximate average cycle time but it won't be real average cycle time as the items completed in that day might not have started exactly that many days earlier. A scatter plot is a better way to judge average cycle time. If the approximate average cycle time is different than the true average cycle time this shows you are messing with the process - for example, if average cycle time is way lower then it means you may be expediting a number of work items and neglecting others which are aging and you'll get widely varying average cycle times.
Kiron
...
1 reply by Aaron Porter
Apr 27, 2022 10:14 AM
Aaron Porter
...
Thanks for the info re: Drunk Agile. I'll have to check it out.
In my case, I'm not using a CFD to show cycle time. Most of the people I'm working with haven't worked with a project manager, before, so I'm being selective and intentional with the information I present. They do understand volume of work and want to see progress; the CFD is one tool to help tell that story.
Again, if this is "true" Kanban and not just calling a work board a Kanban board, you might consider watching some of Daniel Vicanti's YouTube channel "Drunk Agile" videos as he focuses heavily on Kanban.
Aaron - it's interesting that Daniel is not a fan of CFDs. He had almost a full episode dedicated to that. Here are a few of the takeaways I got:
- You cannot tell where bottlenecks are and you shouldn't reflect backlogs in CFDs. The latter is because a CFD should represent arrival into the process and items in a backlog have not arrived in your process. Similarly, a CFD can't be used to show lead time, only cycle time.
- CFDs should not be based on work items (i.e. JIRA does it wrong)
- CFDs can show approximate average cycle time but it won't be real average cycle time as the items completed in that day might not have started exactly that many days earlier. A scatter plot is a better way to judge average cycle time. If the approximate average cycle time is different than the true average cycle time this shows you are messing with the process - for example, if average cycle time is way lower then it means you may be expediting a number of work items and neglecting others which are aging and you'll get widely varying average cycle times.
Kiron
Thanks for the info re: Drunk Agile. I'll have to check it out.
In my case, I'm not using a CFD to show cycle time. Most of the people I'm working with haven't worked with a project manager, before, so I'm being selective and intentional with the information I present. They do understand volume of work and want to see progress; the CFD is one tool to help tell that story. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
All these tools mentioned by Sergio, Kiron and Aaron work well for those who are well versed in agile platforms. My own experience is that senior management wants us to translate all that agile "gobbledygook" into what they are more familiar with: how much of the scope have you completed? When do you expect to be done of everything?
If you haven't already defined what you will provide senior management in your communication plan, I suggest you add it to make sure that: a) you don't drop the ball and b) you set up the data necessary for progress reporting. Saving Changes...
The two main types of metrics I see with Kanban describe a) the efficiency of each cycle/sprint/version release, and b) the performance of the project as a whole.
Metrics like cycle time and throughput tell you how long it takes portions of your complete SOW. That provides velocity. The basic metrics might be a) volume of work completed over the last time period (velocity at one point in time). b) The average velocity over a longer time period along with the variance., and c) The change in velocity; is it going up or down?
Project completion metrics use past data to predict future performance. These include the CFD and burndown charts. Based on the expected velocity measured from prior work completed, how long will it take to complete the remaining work?
The two can be combined to provide more valuable information. For example, "We are currently behind plan based on the burndown plan, but our throughput has increased significantly so we think we can catch up." Saving Changes...
Hi,
Here some metrics you can select from (Depending on your project specificities)
Cost of Delay
Cumulative Flow Diagram
Defect Cycle Time
Defect Density
Defect Trends
Features Accepted
Flow Distribution
Goal Question Metric (GQM)
Number of Change Requests
Spend Graph
Team Morale Score
Value Delivered
Community Champion
