Summary

In this article, we will be discussing a scenario in which the Control Chart is displaying incorrect and unrealistic lead times for different user stories. This discrepancy can potentially cause confusion and inaccuracies in project tracking.

Scenario 1

Upon reviewing the provided screenshot, it is evident that the reported time is 2792 weeks, which is highly unrealistic.

Scenario 2

The Control Chart is displaying incorrect and unrealistic lead time.

Environment

9.x

Diagnosis

• We can obtain the comprehensive output of the Jira REST API to retrieve the complete history (changelog) of all modifications made to a specific issue. This information would be beneficial in gaining insight into when the status of a ticket was altered.  

  <base.url>/rest/api/2/issue/PRJ1-3096?expand=changelog
  <base.url>/rest/api/2/issue/PRJ2-2744?expand=changelog

• To further troubleshoot the issue, we can enable the DEBUG level on the com.atlassian.greenhopper.web.rapid.chart package.

• Also get output of following sql query for both healthy and problematic issue. User have to replace TESCC with project-key and 3 with issue-num.

  SELECT cg.ID, cg.issueid, cg.AUTHOR, cg.CREATED, ci.FIELD, ci.OLDVALUE, ci.OLDSTRING, ci.NEWVALUE, ci.NEWSTRING
  FROM changegroup cg
  JOIN changeitem ci ON cg.ID = ci.groupid
  JOIN jiraissue ji ON cg.issueid = ji.ID
  WHERE ji.id = (select a.id from jiraissue a, project b where a.PROJECT = b.id and b.pkey = 'TESCC' and a.issuenum = '3'); 

• Article JIRA Agile Control Chart Display Erroneous Values would help further to troubleshoot Control Chart.

Cause

Scenario 1

• Control chart retrieves data from the Jira indexes.

• In Jira 8.22.2 and above, a new feature has been introduced that enhances the indexing process. This feature ensures that only the topN issue-related entities such as comments, change history, and worklog are indexed by Jira. You can find more information about this feature at Introducing safeguards to Jira index.

Scenario 2

• It was found that problematic ticket was transitioned to different status at same timestamp.

• This problem is due to the "In progress to Done" transition has an equal date and a lower Change Item ID than the "Open to In progress" transition, this causes incorrect initial Status to be written into the index.

Solution for scenario 1

• Jira admins can change default topN values for these entities by setting a Java property to the desired limit. System property names for issue entities:

  jira.safeguards.indexing.issue.changelogs
  jira.safeguards.indexing.issue.worklogs

• To change these properties, please refer to the KB article How to change Indexing Limit Safeguards in Jira.

• For example, In Jira 8.22.2 and later value for jira.safeguards.indexing.issue.changelogs and jira.safeguards.indexing.issue.worklogs is by default set to 100. This is mentioned in Introducing safeguards to Jira index. So user can set JVM properties like

  JVM_SUPPORT_RECOMMENDED_ARGS="-Djira.safeguards.indexing.issue.worklogs=500 -Djira.safeguards.indexing.issue.changelogs=500"

Solution for scenario 2

• It appears that some script or automation is performing this transitions at same timestamp. It is recommend to wait for one operation to fully complete before starting a new one. That script or automation should be reviewed.
• There is no any way to fix broken report with this problem where transitions are done at same timestamp.