Sprint Report Inaccuracies after Workflow Change
Platform Notice: Cloud and Data Center - This article applies equally to both cloud and data center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
Jira Software loses viability on an issue's change history when a previously existing status is removed ( changed ) from the project's workflow. This affects sprint reports for both current and closed sprints. It also affects any status that is in the far right corner (Done) or the far left (To Do).
Steps to Reproduce
Situation A.
- Configure a workflow with the following statuses:
Open -> In Progress -> Resolved -> Closed - Create a sprint, add an issue from the backlog, transition every step from Open until Closed, and complete the sprint
- Create new workflow with the following statuses:
Open -> In Progress -> Status 9 - Change the workflow for the project, or issue type, map issues in Resolved and Closed to Status 9
Situation B.
Update the statuses in a current workflow that are mapped to:
- To Do
- Done
Expected Results
Sprint reports are unaffected by this change.
Actual Results
Sprint report show issues moved from Resolved and Closed to Status 9 removed From sprint. Cycle Time is also incorrectly calculated for these issues as well.
Notes
Other Sprint reports may be affected from this change.
While the original report comes from Jira 6.4 / Jira Agile 6.7, we were able to reproduce this problem in Jira 8.x as well. This can affect any status on the far right or far left. For example, if you leave out a to do status from the old workflow, the sprint report will not see that the issues were ever "started" and it will negatively affect burn-down and velocity.
Workaround
Modify the affect project's workflow, add changed status back, and map this status to a column in the project's board (respective to their position in the old board i.e. far right or far left). They do not need transitions to or from other statuses. In the example above, Agile reporting is fixed by adding Resolved and Closed back to the affected project's workflow and mapping the statuses to the Done column accordingly.
For more information see JSWSERVER-16687 - Getting issue details... STATUS