HI Daniel Dudziak, this product defect has been reported for several years without a resolution. Why is Atlassian Jira Software product support not prioritizing this major product defect? All of our reports are now inaccurate and the workaround solution is not optimal. I am requesting to revisit this product defect and discuss further with your senior management and product management.

It's been 6 years since this software defect has been reported. Why isn't this defect resolved by now. Where is our Atlassian Jira Product Manager / Owner who is representing the voice of the customer. Please prioritize this product software defect instead of working on dark mode feature.

Found a quick and easy fix for this- at least in the server version.  Since the reports are based off the columns in the board instead of the issue statuses themselves (take a look at the cumulative report- you see column headings- not statuses) simply delete and re-create your columns. 

We were standardizing projects where some had the final status of "Done" and others "Closed". We wanted them all as "Closed", so created standard schemes and moved all projects to those schemes.  Where Done was changed to Closed, we lost all of our completed issues in our reports.

Went into the board settings and deleted the column for "done", and replaced it with a new column "closed".  Viola!  All of our completed issues magically re-appeared!

We came across this bug on 7th of June 2023, just when this update comment was made.

Our testing to put the status back (and bulk migrate issues back to that old status) did not resolve the problem - and we're not happy to apply this workaround en-mass unless it works for our testing.

Any other things to try?

Can devs tell us what the fields that the reporting is reading off - for sure they are fields we can't see with frontend - but people might be able to fix data in the database directly - if there's documentation on how the reporting functions work.

Look at the logic for the BURNUP Charts which work before and after conversion with historical data!

Can we please get movement on this bug? It is impacting nearly a dozen of our engineering teams

Hi Atlassian,

I think you should read this great article I found on the web: https://www.atlassian.com/agile/scrum/scrum-metrics

It says:

Summary: Scrum metrics are specific data points that scrum teams track and use to improve efficiency and effectiveness. Scrum teams use metrics to inform decision-making and become more efficient in planning and execution, as well as set target goals and improvement plans.

“If you can’t measure it, you can’t improve it,” noted famous management thinker Peter Drucker. While this isn’t a statement that applies to every facet of life, it does apply to teams practicing agile scrum. By using certain metrics, scrum teams can adjust, pivot, and refine team effectiveness.

Looks like your teams don't really understand the importance of having reliable data with which to measure, track, and improve. It's possibly one the most important aspects of agile methodologies, in my (and your) opinion. Such a bizarre disconnect between your marketing/outreach and dev teams...

We recently made a status change in our default workfow, used by a couple of hundred teams. This known error really caught us off guard. The teams are negatively affected by this: they are missing crucial steering- and report information.

• Velocity cannot be determined anymore for current sprints / releases;
• Data can not be compared anymore to previous sprints;
• All in all, the report information now feels 'inrealiable" to our users.

I'm really surprised, that this major error is still "gathering impact" and prioritized as Low. As our Jira users grow rapidly (>5000), we are continuously optimising our configuration. And we should be able to make changes - like this status change - without losing information along the way, and without users losing confidence in the tool.

Please, implement a solution for this error and give it more priority.

We too suffer from this problem. A recent fix in our workflow renders all reports of previous sprints useless. Detemination of velocity for multiple teams is impacted.

This is a SEVERE and MAJOR problem with the basic functionality of Jira that renders the system useless.  If we can't make workflow changes for any reason whatsoever this is a show stopping BUG!  Using Jira Datacenter

• v8.14.0#814001

We have a project to cleanup the workflow statuses on our Jira instance running on 8.5.8, however, due to this issue we are unable to achieve our requirement. Please provide a solution to this issue.

Can we get prioritize this issue please? Don't think Symptom Severity: Severity 2 - Major means it can be open for 2 years. Cmon Atlassian. 

We have this problem on 8.11.0 Data center.

This is happening to my team, however we're on CLOUD and not server.  I added an additional workflow step (in the done category), however now Sprint Reports see them as In Progress, and not in the new status.  If you go into the query (in the sprint report) it appears in the correct status.  

TLDR - if you change a workflow for issues in sprint, some may not appear to map correctly to the new statuses inside sprint reports

Hi Team , any solution for this issue  .  

Significant impact as well. We updated our workflow to add future steps, and all issues from previously closed sprints moved into our backlog. 

We created company templates and slowly moving projects to our new template, after migrating old sprint reports does not show any story points since closing statutes haved change a lot compared to very old templates.

The workaround is not a good idea, we would have to keep old statutes in our new templates, Jira should manage this properly by itself.

We have over 9000 users and more and more are complaining about this problem, will Atlassian do something about it?

Just happened to me as well with the workflow change. It's a concerning result.

We've also seen the mismatch, do we have an idea when this issue will be better handled?

This is affecting us as well (another very large enterprise customer). Agree that this should be ranked higher.

I think that this problem should be a bit higher.  If they are encouraging a healthy Jira environment, but implementing unification changes for states across the instance (if you have 40 statuses that mean nearly the same thing), when you attempt to convert a workflow to utilize one and remove the old state off of the board, it messes with the area's sprint and velocity reports. In my mind, this should have snapshot of what it was when the work was done on the sprint, not how the board's current state is.

Possibly due to the creation of a new workflow and the deleting of the previously used one, the workaround does not appear to work for my organization.

This appears to be affecting us as well. Doing more testing but at first glance we are seeing exactly this.

Also having this issue (in cloud). This impacted 4 projects during an audit period, and could have had extreme consequences for those teams.

+1 another large enterprise customer running 7.10.1 and seeing this same issue. The work around definitely works, but is certainly inconvenient.

I'm having the exact same issue. Trying a re-index to see if that helps...at its surface this seems like a pretty big bug......we're a VERY LARGE enterprise customer running JIRA v7.6.7