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 a big fan of using the CFD but I find the Jira implementation qwerky. Here is an example. The first image shows a typical shape as things progress between the various columns - all looks good. Because of the known and irritating issue of the y axis not scaling according to the Report Timeframe selected, I want to filter out transitions to the column with the big red band "Closed". Now rather than cumulating the line representing an issue entering a column state goes down. This only happens in a Jira CFD in my experience if issues are transitioned backwards or deleted. So why does just filtering out transitions to Closed change the other states ? This is is a Kanban Board with one state mapped per column and Closed is the rightmost state on the Board.
Hi @Rees_ Ian
First thing, when any columns/steps are removed from a CFD, particularly "completed" it is no longer a CFD, and so what you see is what I would expect.
And I agree with you on the Jira interpretation of a CFD, as it has many challenges...often making it less useful when flow has anything beyond the basics of to-do, doing, and done. It doesn't even encourage users to exercise conservation of flow. Anyways...
So your options include finding an actual CFD from the marketplace, download the data (including history) and build your own, or build a quick filter to exclude issues which move backwards in flow (or are abandoned).
Thanks for your help Bill - yes build my own or using something like ActionableAgile tools still looks like essential if you want a working CFD. However, I don't understand the assertion that by filtering out the transition to a particular state that it is no long a CFD. I think it is as I am only trying to filter the view.
I could possibly build a quick filter to exclude stuff that transitions backward (can't do that if deleted) but I don't think that is the point - the issues aren't transitioning backwards or being deleted - if they were then I would expect to see issue counts going down - it is just that by filtering out one state, it APPEARS as though issues have probably been transitioned backwards. Jira still lags behind somewhat in this very important chart. does anybody find it usable at all beyong a simple To Do - in Progress - Done workflow ?
I have lots of other useful reports implemented in Tableau using a Jira connector for the source so maybe I need to see if I can create a CFD in Tableau.
@Bill Sheboy in the second diagram - where it is not cumulative - are the WIP bands still meaningful i.e. is it still safe to assume that widening of the band is an increase in WIP ? I've sort of lost confidence in using it to diagnose something when it's a CFD that doesn't Cumulate. I've have used Quick Filters such as 'status changed after startOfDay(-3M) to Closed ' to help with the non-scaling Y-axis problem but of course that also has the problem that you don't see the issues that haven't yet closed but are transitioning through the workflow.
In your second image where you appear to have removed completed issues, it could help to see variation in count by board column/status, but not cumulatively as that aspect has been removed. The completed items no longer overwhelm the result display.
And as you note, the Jira "CFD" does not correctly preserve the y-axis scale for all of time; if it instead preserved scale *and* zoomed into a point, you could see accurate variation in workflow.
Hi Bill, thanks for your insight as always - I still don't get why removing one state in a CFD would stop the other columns still showing up cumulatively - am I missing something
Say there was a steady flow of one issue entering the system each day since the beginning of the year and each day, every issue moved onto the next state and the flow was Backlog->Discovery->Refinement->Sizing->In Progress->Done, why would removing the transition to Done from the display change the accumulating numbers in the other states? It doesn't really matter because I have found a solution to get the y-axis on an appropriate scale is to add a Quick Filter something like 'status changed after startOfDay(-90d)' and refine the report with the Quick Filter.
However, I just like to understand
Hi @Rees_ Ian
A cumulative flow diagram (CFD) sums the final, completed status of the workflow, with the other status values displayed without summation, making visible the process states at different times...and so several useful measures appear.
In your example of removing the Done status from the display, that does not change the workflow to make "In Progress" into the "completed" category for the CFD. And so it does not start accumulating the net-total over time for "In Progress" instead.
Instead removing Done from the display essentially creates a WIP count over time chart.
Thanks Bill - a great explanation. My assumption was in fact that removing the Done status from the display, effectively changed how you wanted to consider the workflow - and I think that would be more useful because in Atlassian's implementation once you remove a state from the display, the top line doesn't represent the cumulative arrivals to a state and the bottom line doesn't represent the cumulative departures from that state so it is no longer a CFD.
As I mentioned, I have found that by adding a quick filter to something like 'status changed after startOfDay(-90d)' and refining the report with the Quick Filter, I can largely get over the problems with the inappropriately scaled y-axis. Thanks
Yup...that y-axis is a problem for this interpretation of a CFD, and it is the reason many customers either use a marketplace addon to draw these or build them using exports and history log pulls.
The documentation indicates it is the x-range only which impacts the y-axis scale...but that is not always true. For some data you can exclude the outliers and the y-axis will return to linear scale. Please look here to see one method for removing the outliers: https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-control-chart/#Tips-and-examples