Jira Reports: Control Chart does not take into account Story Points

[Ludmila Portugeis]

Hello,

My team is working in Kanban, and I am using the Control Chart report to view the Cycle Time and analyze team performance.

Stories have different weight (Story Points), however the Control Chart report does not take into account the story points when calculating the average and the rolling average. The calculation is based on the cycle time of the issue itself and the surrounding issues. 

How can story points be reflected in the calculation or by other words how can I get the report based both on story points and cycle time of the issues?  

[Stefan Peruzzi · Accepted solution]

ups - I wrote this in the wrong section ... so here again:

Hi,

I usually create quick filters for groups of stories like 1-3 SP, 5-8 SP, 13 SP or a different grouping and then use the control chart only with these filters active to learn about cycle time.

[Emre Toptancı _OBSS_ · Accepted solution]

Hello @Ludmila Portugeis ,

In fact you shouldn't be analyzing all issues at once on a Control Chart. Keep in mind that most of the time the story point scale is not linear. Even if you are not using a Fibonacci Sequence, it is not healthy to say that a 20 point story is twice as big as a 10 point story. Looking at different issues with different story points would be like comparing apples and oranges. 

Naturally, the Control chart does not have an option to incorporate Story Points into the chart because mathematically it doesn't make sense.

The recommended way would be to look at the Control Chart each time using issues with same (or at least similar) sizes. In that case, you will need to analyze different Control Charts but the results will be meaningful. And (by comparing those charts) you can even discover how story size affects your process.

By the way, our team at OBSS built Time in Status app for similar needs. It provides reports that are more detailed and flexible than Control Chart. It is available for Jira Server, Cloud and Data Center.

Time in Status mainly allows you to see how much time each issue spent on each status so you can see status times for each status separately. You can combine statuses in any way into consolidated columns to see metrics like Ticket Age, Cycle Time or Lead Time.

You can also calculate averages and sums of those durations grouped by issue fields you select. For example see the Average Cycle Time for each story point size segment.

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions. Sort and Filter according to report values.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example see average InProgress time per project and per issuetype.)
• Export your data as XLS, XLSX or CSV.
• Access data via REST API. (for integrations)
• Visualize data with various chart types.
• See Time in Status reports on Jira Dashboard gadgets

https://marketplace.atlassian.com/1211756

EmreT

[Stefan Peruzzi]

Hi,

I usually create quick filters for groups of stories like 1-3 SP, 5-8 SP, 13 SP or a different grouping and then use the control chart only with these filters active to learn about cycle time.

[John Worrall]

@[deleted]

I disagree with the assertion that it does not make sense to view story points in the control chart (and it bothers me when people blanket state that you shouldn't look at information a certain way).

I have set up a board with quick filters that allow me to break the report down to show stories of different story point sizes.

Why?

Because as we make adjustments to our process, I like being able to see if those process changes indicate a positive or negative efficiency impact on complex stories vs non-complex stories.

We may, for example, implement policies around unit test coverage or peer review that may make simple stories less efficient, but could have a huge efficiency impact on stories that are trickier. Armed with that information, we are better able to determine if it is wise for us to keep the policy in place, can it, or fine-tune it to apply in certain scenarios where it's shown to have more benefit.

Please don't tell people that they don't need information that they are looking for. There are almost always useful applications for information.

[Emre Toptancı _OBSS_]

Hello @John Worrall ,

I totally understand and agree with you. This is what I recommended in the first place. Two quotes from my earlier post:

"In fact you shouldn't be analyzing all issues at once on a Control Chart."

"The recommended way would be to look at the Control Chart each time using issues with same (or at least similar) sizes". 

I didn't get into details about defining quick filters and such, but that is what I was pointing at. I am sorry to hear that I couldn't phrase it clearly enough.

In either case, thank you for the feedback.