Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,456,701
Community Members
 
Community Events
176
Community Groups

Using story points for a more accurate cumulative flow diagram

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?

3 answers

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.... 

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.

Like # people like this

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

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/ 

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

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 :)

Like Tsafrir Meir likes this
0 votes

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"?

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.

I never said that was what they were for.  

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events