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

Burndown report includes time remaining from Resolved and Closed issues.

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Answered
    • None
    • None
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      The agile burndown chart uses the issue's Remaining hours field even if the issue is resolved. This makes little sense--if the issue is resolved, then by definition it has 0 remaining time.

      This is a big annoyance: the chart becomes wildly inaccurate if we use less or more time than estimated to satisfy issues. This makes a mess of time reporting and is a pointless step since, again, a resolved issue has no remaining work. Otherwise, it shouldn't be resolved.

      Further, what if we need to reopen the issue? It would be nice to keep burning against its remaining time instead of having to totally re-estimate because we had to manually force it to 0 time before closing it.

      Here's a use case:

      Time estimate: 4 hours
      User resolves issue: 2.5 hours
      Time remaining: 1.5 hours
      Issue is re-opened for incomplete fix, and user logs another hour on the same issue. If this works properly, then the report just works.

      If we adjust the time remaining either manually or with a post action, then it will have have scope adjustments at Resolve, and then scope adjustments at Reopen and then scope adjustments at Resolved again. We are doing what you suggested now, and it renders the Burndown chart a bloody mess. It's not just a workaround, it's a bad hack with nasty side effects.

      This also requires users to type in a lot of information, and to do the data input perfectly (as there is no supported method for fixing mistaken input, see GHS-7773). This is a perfect place for very simple automation. This is likely a 15 minute fix on that report.

      Expected behavior: If I resolve an issue, the agile burndown chart should consider the issue as having 0 remaining time regardless of the value of its Remaining hours field.

          Form Name

            [JSWSERVER-8340] Burndown report includes time remaining from Resolved and Closed issues.

            Michael Tokar added a comment -

            Many thanks for reporting this issue, however this is not something we plan to add to JIRA Agile at this time.

            We would not consider adding an option to the chart which results in the visual representation being misaligned with the true data underpinning it. While this might suit your particular use cases, there are likely many other customers who would find this difficult to understand.

            As discussed there are work arounds to this. Re-estimating issues if you manually set their estimate to zero shouldn't be that difficult, as you can access the history of the issue's estimate field to retrieve the last known value. You can also add the Time Tracking field to the screens on which you resolve issues, so that you can set the estimate to zero in that action.

            If the JIRA workflow post function is not working (as discussed in the linked bug) then that will be addressed separately. But as far as this feature request goes, we will not be fulfilling it.

            Regards,
            JIRA Agile Team

            Michael Tokar added a comment - Many thanks for reporting this issue, however this is not something we plan to add to JIRA Agile at this time. We would not consider adding an option to the chart which results in the visual representation being misaligned with the true data underpinning it. While this might suit your particular use cases, there are likely many other customers who would find this difficult to understand. As discussed there are work arounds to this. Re-estimating issues if you manually set their estimate to zero shouldn't be that difficult, as you can access the history of the issue's estimate field to retrieve the last known value. You can also add the Time Tracking field to the screens on which you resolve issues, so that you can set the estimate to zero in that action. If the JIRA workflow post function is not working (as discussed in the linked bug) then that will be addressed separately. But as far as this feature request goes, we will not be fulfilling it. Regards, JIRA Agile Team

            Stefan Wallin added a comment -

            There should be an option in the burndown chart to include resolved and closed issues in remaining estimate. This would fix the problem for most use cases IMHO. Vote added.

            Stefan Wallin added a comment - There should be an option in the burndown chart to include resolved and closed issues in remaining estimate. This would fix the problem for most use cases IMHO. Vote added.

            John Crim added a comment -

            I think it's correct that resolved issues should still have time tracked to them - if "resolved" means dev complete, and "closed" means QA verified, then the post resolved time is the estimated time for QA. I don't think it's desirable to remove that time from the burndown. I think it would be better to support the post-function clearing the remaining time on resolution, if that makes sense in a given team's workflow..

            I do however agree that remaining time on closed issues should not count toward remaining time on the burndown chart.

            John Crim added a comment - I think it's correct that resolved issues should still have time tracked to them - if "resolved" means dev complete, and "closed" means QA verified, then the post resolved time is the estimated time for QA. I don't think it's desirable to remove that time from the burndown. I think it would be better to support the post-function clearing the remaining time on resolution, if that makes sense in a given team's workflow.. I do however agree that remaining time on closed issues should not count toward remaining time on the burndown chart.

            Aren Cambre added a comment -

            I linked GHS-6788 to this because fixing this bug appears to be a better resolution to the problem. GHS-6788 seems like a workaround.

            Aren Cambre added a comment - I linked GHS-6788 to this because fixing this bug appears to be a better resolution to the problem. GHS-6788 seems like a workaround.

            Fabian Meier added a comment -

            That's the one I am talking about: GHS-6788

            Fabian Meier added a comment - That's the one I am talking about: GHS-6788

            Fabian Meier added a comment -

            We used to have a post-function that clears the remaining estimate when closing an issue - however, there is a bug in Greenhopper that gets the estimate tracking of GH and JIRA out of sync and ruins your burndowns...

            So even the workaround is not working doh

            Fabian Meier added a comment - We used to have a post-function that clears the remaining estimate when closing an issue - however, there is a bug in Greenhopper that gets the estimate tracking of GH and JIRA out of sync and ruins your burndowns... So even the workaround is not working doh

            Jo Rhett added a comment -

            Here is another ticket with the same expectations, which was likewise closed as "won't fix"

            Jo Rhett added a comment - Here is another ticket with the same expectations, which was likewise closed as "won't fix"

            Aren Cambre added a comment -

            I agree that "won't fix" is completely unacceptable. The current state is broken, and the workaround screws up issues and/or requires way too much manual effort.

            Aren Cambre added a comment - I agree that "won't fix" is completely unacceptable. The current state is broken, and the workaround screws up issues and/or requires way too much manual effort.

            Jo Rhett added a comment -

            This was originally opened as GHS-3867 but was closed as "won't fix" since the user can do the data input themselves. I have explained in detail in this ticket why that answer is completely unacceptable.

            Jo Rhett added a comment - This was originally opened as GHS-3867 but was closed as "won't fix" since the user can do the data input themselves. I have explained in detail in this ticket why that answer is completely unacceptable.

              Unassigned Unassigned
              8372cf0e6631 Jo Rhett
              Votes:
              13 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: