Using story points for a more accurate cumulative flow diagram

[leewarren]

The CFD just shows case counts, but what I'd really like is for it to weight those cases by story points, otherwise seeing what's in the queue is far less accurate. Is there a way to do this?

[Tsafrir Meir]

We also need this - the option to view the CFD in terms of story points. It does make sense and can be very helpful to visualizing and understanding the trend and developing gaps. The CFD should shows the amount of work in each state, at any given time. That "amount of work" can be expressed in different units - you can simply count issues, count story points (or even count original estimates - for teams choosing to use time tracking...).

Atlassian - PLEASE add this functionality, listen to your customers.... 

[Nic Brough -Adaptavist-]

That's not what CFDs are for, Atlassian are unlikely to add this.

Remember, in Kanban, every issue estimate is the same, it measures throughput, not size.

[Tsafrir Meir]

"in Kanban, every issue estimate is the same" - any reference for this?

[Nic Brough -Adaptavist-]

Almost everything I read on Kanban talks about Kanban estimation, either up-front, or as the first question.  So I'll quote one of the better articles I've got bookmarked.

"Let’s get one thing straight from the start: there’s no estimation in Kanban."

Kanban looks at throughput and cycle times, not estimates.  "Every card is the same size" is just a trick to give the people who don't understand Kanban a way to put numbers on it so they stop bothering the team for estimates.

My quote was nicked from https://kanbanize.com/blog/kanban-estimation/ 

[Bill Sheboy]

Hi @leewarren 

Changing a Jira CFD to measure based upon something other than count isn't currently possible and has been suggested as a feature for at least a decade: https://jira.atlassian.com/browse/JSWCLOUD-2785

You do not clarify what problem you are trying to solve, and so why measuring a CFD with story points could help.  IMHO, changing to use a Jira CFD with something other than item counts may not be more accurate to measure flow, and so it may not help as you asked.

• The CFD in Jira is Atlassian's interpretation of a cumulative flow diagram, and does not check or enforce the ideas of conservation of flow, steady-state arrival, steady-state departure, inclusion of all value stream steps, that no line on a CFD can ever decrease, and x/y-axis scaling based upon the origin point.  So altering the measure may worsen the impact of those issues.
• And, counts are counts; they are the smallest unit (except by further decomposing of work).  But story points are a relative-size/complexity/effort forecasting tool.  That sizing will certainly change over time, even for a single team.  Given these different units of measure (one fixed and one variable), measuring WIP, lead time, cycle times, etc. would have suspect value with story points.

Perhaps a better tool would be a burn-up chart on story points, for a narrow window of time of 3-5 release cycles, to see impact on flow and progress for a scrum team.  If you are interested in other measures, please investigate other reports or versions of the CFD from the marketplace...or export data and craft other reporting.

Kind regards,
Bill

[leewarren]

Changing a Jira CFD to measure based upon something other than count isn't possible

- Of course it's possible. It's software :)

You do not clarify what problem you are trying to solve, and so why measuring a CFD with story points could help.  

- Because not all issues are of the same scope. If I want to project a release based on the CFD, this makes it harder to do.

IMHO, changing to use a Jira CFD with something other than item counts may not be more accurate to measure flow, and so it may not help as you asked.

- Respectfully disagree. A teeny issue and a big issue are clearly not the same.

• The CFD in Jira is Atlassian's interpretation of a cumulative flow diagram, and does not check or enforce the ideas of conservation of flow, steady-state arrival, steady-state departure, inclusion of all value stream steps, that no line on a CFD can ever decrease, and x/y-axis scaling based upon the origin point.  So altering the measure may worsen the impact of those issues.

- A trend line can be drawn from a CFD pattern just like any other. respecting the noise you describe.

• And, counts are counts; they are the smallest unit (except by further decomposing of work). 

- Not all counts are the same.

• But story points are a relative-size/complexity/effort forecasting tool. 

- Exactly, which is why weighting the CFD by story points has been repeatedly requested.

• That sizing will certainly change over time, even for a single team.

- Not empirically established. Story points for a particular team might actually become *more accurate* over time.

• Given these different units of measure (one fixed and one variable), measuring WIP, lead time, cycle times, etc. would have suspect value with story points.

- Not when measured across several sprints with smart projection of likely growth and with a concrete "definition of done" for cases.

Perhaps a better tool would be a burn-up chart on story points, for a narrow window of time of 3-5 release cycles, to see impact on flow and progress for a scrum team.

- That would not let me examine the queue of total work against its satisfaction.

  If you are interested in other measures, please investigate other reports or versions of the CFD from the marketplace...or export data and craft other reporting.

- I am interested in getting my mission done, not building more tools :)

[Dan Allford]

In short, size matters! 

[Nic Brough -Adaptavist-]

I don't think this is quite what CFDs are for. 

CFDs tend to be used for (support) Requests mostly because the issue throughput is what they are intended to report on.  Yes, the amount of time in various phases of the process, but not effort or complexity.

I have a doubt that people asking for story-point based CFDs are looking for the wrong reports for them.  They're not wrong in what they are asking, but CFDs are not the right answer, they should be looking to other reports.

I think you can probably see that the question I am heading for is "how would a CFD based on story points (which we don't usually apply to service requests) help people understand what is happening"?

[leewarren]

CFDs primary purpose is not for support requests. If you search "what are cumulative flow diagrams used for" you get:

https://www.planview.com/resources/articles/cumulative-flow-diagram/

The Cumulative Flow Diagram is a tool that lets teams visualize the progress of their projects. Teams can monitor the flow of work through its stages and gives the user the ability to predict blockers or disruptions in the progress of work.

The Cumulative Flow Diagram comes from the practice of Kanban and is used to determine the efficiency of teams and their workflow process.

[Nic Brough -Adaptavist-]

I never said that was what they were for.  

Yes, CFDs came from Kanban, that's why they measure throughput rather than effort.

[Dan Allford]

CFDs can and should be used for Scrum and ‘scrum ban’. A bottleneck at PO / BA / epic or story preparation stage is still a bottleneck. A bottleneck in a manual regression testing team is still a bottleneck. 

Proof it’s needed in Scrum: the sheer hassle I’ve gone through to generate story-points based CFDs to understand bottlenecks affecting around 20 scrum teams on a major project. 

From 1pt to 20pt stories - from 5pt to 100pt+ epics - size matters!

[Nic Brough -Adaptavist-]

I don't think you quite understand throughput vs sizing.

[Tsafrir Meir]

I don't think you understand the need that we're all trying to explain...

[Nic Brough -Adaptavist-]

It's perfectly clear what you're explaining - you want a certain type of report which is absolutely not a cumulative flow diagram, and you're asking for a CFD to not be a CFD to do it.

There's nothing wrong with the report you're asking for.  The problem is that it's not a CFD, and hence the CFD report in Jira is not able to do it.  A CFD is for measuring throughput, not size.

[leewarren]

OK, so how about retaining the orthodox CFD and add a new "Unorthodox CFD" that weights by story point? :)