Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-16687

Migrating workflows on existing projects can impact Agile reporting if statuses are changed

    • 6.07
    • 62
    • Severity 2 - Major
    • 12
    • Hide
      Atlassian Update – 19 July 2024

      Dear Customers,

      Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog.

      The workaround for this bug is as follows:
      Modify the affected project's workflow, add the changed status back with no transitions, and map this status to a column in the project's agile board (respective to their position in the old board i.e. far right or far left)

      Please continue watching this ticket for future updates and changes in the timeline that impacts your work.

      Best regards

      Daniel Dudziak

      Jira Developer

      Show
      Atlassian Update – 19 July 2024 Dear Customers, Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog. The workaround for this bug is as follows: Modify the affected project's workflow, add the changed status back with no transitions, and map this status to a column in the project's agile board (respective to their position in the old board i.e. far right or far left) Please continue watching this ticket for future updates and changes in the timeline that impacts your work. Best regards Daniel Dudziak Jira Developer

      Summary

      It appears 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 the historical reporting on the various agile charts for the affected project.

      Steps to Reproduce

      1. Configure a workflow with the following statuses
        1. Open -> In Progress -> Resolved -> Closed
      2. Create a sprint, add an issue from the backlog, transition every step from Open until Closed, and complete the sprint
      3. Create new workflow with the following statuses
        1. Open -> In Progress -> Status 9
      4. Migrate workflow, map issues in Resolved and Closed to Status 9

      Expected Results

      Agile reports are unaffected by this change

      Actual Results

      Sprint report show issues moved from Resolved and Closed to Status 9 as being In Progress and Removed From Sprint. Cycle Time is also incorrectly calculated for these issues as well. See attached screenshots.

      Issue history:

      Sprint report:

      Notice how the Sprint report shows issue 1 as Open instead of Status 9

      Notes

      Other Agile reports may be affected from this change.
      While the original report comes from Jira 6.4 / Jira Agile 6.7 we reproduced this problem in Jira 7.11 too.

      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 burndown

      Workaround

      Modify the affect project's workflow, add changed status back, and map this status to a column in the project's agile 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. See attached screenshot.

        1. issue-history.png
          issue-history.png
          260 kB
        2. sprint-report-bad.png
          sprint-report-bad.png
          139 kB
        3. sprint-report-fixed.png
          sprint-report-fixed.png
          185 kB

          Form Name

            [JSWSERVER-16687] Migrating workflows on existing projects can impact Agile reporting if statuses are changed

            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.

            John.Morales added a comment - 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.

            John.Morales added a comment - 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.

            Why has this Jira product defect has not been fixed yet? We are now encountering this issue after we renamed a few Jira statuses for standardization. We can not revert the Jira statuses that were not renamed...... 

            John.Morales added a comment - Why has this Jira product defect has not been fixed yet? We are now encountering this issue after we renamed a few Jira statuses for standardization. We can not revert the Jira statuses that were not renamed...... 

            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!

            Michael Ballenger added a comment - 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!

            Eric Lee added a comment -

            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.

            Eric Lee added a comment - 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.

            Atlassian Update – 07 June 2023

            Dear Customers,

            Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog.

            The workaround for this bug is as follows:
            Modify the affected project's workflow, add the changed status back with no transitions, and map this status to a column in the project's agile board (respective to their position in the old board i.e. far right or far left)

            Please continue watching this ticket for future updates and changes in the timeline that impacts your work.

            Best regards

            Sławomir Zaraziński

            Jira Developer

            Sławomir Zaraziński added a comment - Atlassian Update – 07 June 2023 Dear Customers, Thank you for taking the time to file and comment on this issue. We realize it still occurs and impacts your organization. We are now working on multiple customer requests and on new features, so we have to postpone our resolution of this issue. We’ve decided to move this issue to our long-term backlog. The workaround for this bug is as follows: Modify the affected project's workflow, add the changed status back with no transitions, and map this status to a column in the project's agile board (respective to their position in the old board i.e. far right or far left) Please continue watching this ticket for future updates and changes in the timeline that impacts your work. Best regards Sławomir Zaraziński Jira Developer

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

             

            2Manyc0des! added a comment - 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

            Abiy Kaltiso added a comment - 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...

            Desmond Cox added a comment - 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.

            Michelle de Bruijn added a comment - 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.

              Unassigned Unassigned
              jcurry Jeff Curry
              Affected customers:
              95 This affects my team
              Watchers:
              90 Start watching this issue

                Created:
                Updated: