Seems like something that should be fixed, the data is wrong and now I have to manually calculate since I want business days.  Basically, this report only reports for all days not business days until this bug is fixed.  It would be better than for me to be able to configure the report to display days and not convert to weeks, I don't see a way to do this, is this possible?

I've resorted to always checking "Include non-working days in calculations"

• It's immediately relevant to audience in real calendar concepts
• It avoids the gnarly "pure KPI metric" conversation detangling "weeks" meaning "containers of 7 working days"

I think this is an intentional "feature" to springboard customers to buying community add-ins that do it right.  If one could ever find such a set.

There is no use for the charts if they don't represent relevant info. This is a part of basic stuff for the charts - please fix this.

Adding a +1 to this.  It's been almost 5 years since this reported, any update to share on a fix for this?

Hi there, this issue has been impacting my team since 2019. I figured out by manually calculating cycle time for a few individual issues that the 1w actually equates to seven working days. So a 1w 3d on my control chart actually means 10 working days total. To avoid confusion, I report my cycle time in number of working days. That doesn't resolve the issue, though. 

It's been a year since I've looked at the control chart and I'm disappointed to see this is still an issue. I had to revisit to remind myself of the calculations. What would it take to get this addressed? Cycle time is a key Agile metric!

In the absence of this bug fix is there any help on how to interpret the charts data. Like should Avg time 23 h be treated as 23 hours to close an issue and Median like 1d 2h be treated as 26hs to close an issue? It is confusing how to interpret this data.

I can't understand why Atlassian won't document how to read the chart data but leave it with explanation that is inadequate in their sites.

Seeing that this is 2 years old, and  ranked low (for reasons unknown as this is not a cosmetic bug) i don't see this getting fixed for a long time to come.

Agree with the previous commentators on this. It undermines team's faith in reports. Having an unreliable inaccurate reporting mechanism is even worse than having no reporting at all. It impacts teams' abilities to accurately assess cycle time and to plan work. Please fix!

this one is a real pain and like Igor says above, it really does make teams doubt these reports  

Please fix - especially for those who are using these charts on a quarterly basis for reporting purposes. thank you

Please fix it. It's extremely misleading and makes teams doubt the usefulness of Jira reports at all ;( 

Being able to define a work week has been included in PM software since the late 1980s. (see Timeline by Breakthrough Software, https://en.wikipedia.org/wiki/Breakthrough_Software). When tasks are begun the day before a span of "non working" days, it distorts the accurate identification of real delays in project tasks. It also changes the team's response to tickets to not work them as soon as possible but trains them adjust to the arbitrary deficiencies of the software which create their numerical scorecard.

I suppose the work around is to export project data from Jira periodically and perform actual (real) metrics on it.

"Minor" Bugs like this are effectively destroying the customers confidence in the validity of the Jira reports.

Correct reports are an absolute Must Have!

Having to deal with crap like this is exceedingly frustrating, especially when using the control chart for enterprise-wide KPI/trend reporting 

Fix it!

Yes, this bug makes unusable one of the most powerful features of JIRA–drawing insights from the high volume of data to help organizations improve.  The last thing I need is for people to disregard the stats we have because of a simple bug in the time calculations.

The severity of this ticket ought to be upgraded by Atlassian as it hugely impact the improvement we can make in the flow when the control chart metrics is giving unusable data. 

Kirill Klimov wrote a great piece in InfoQ on how to handle bugs: basically take a Now or Never approach. If you know you'll likely never fix a bug, log a workaround for your users, mark the bug as such and disable voting and commenting. Don't mess around with bugs still in, "Gathering Impact" a year after they've been reported. It's not intellectually honest and it's costly to us Ifor the reasons Dan Driscoll gives above) and to you because presumably you have a human or two responsible for going over these bugs from time-to-time.

https://www.infoq.com/articles/strategy-handling-defects

Talk about a confusing mix of semantics. This should just be fixed.   Does it really require 1000s of up-voting?

Or at least add some verbiage about this into the "How to read this chart" to save your users from time searching the internet community boards and ultimately this defect.

Issue also include converting hours to days.  A configured 8-hour day is disregarded and a 24-hour day is used.