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

Add ability to control start and end date for Agile Gadget charts...

XMLWordPrintable

    • 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 start and end date used in drawing the Agile Gadget graphs is derived roughly as follows:

      1. Before preparing the chart, issues are filtered:
        • Issues that aren't in a GreenHopper-enabled are excluded
        • Issues that don't have at least one unreleased fix version selected are excluded
      2. The list of versions is created based on the fix version associated with issues included in the filtered list.
      3. The earliest start date is selected from the list of versions.
      4. The latest end date is selected from the list of versions.

      The end date for each version is determined by looking at (in order):

      1. The end date configured in the planning board when viewing the version
      2. The release date of the version
      3. Today's date

      This can lead to unexpected behaviors, such as when viewing a filter that uses "child" versions. Since "child" issues are also associated with the "master" version, the end date of the "master" version is included in the calculation. This makes it difficult to construct cross-project graphs that are targeted to specific "child" versions.

      Adding the ability to set an end date manually (or to peg the end date to a specific version) would reduce the confusion.

            [JSWSERVER-1991] Add ability to control start and end date for Agile Gadget charts...

            Tadhg Tadhg added a comment -

            @JC

            That is great news - many thanks for the prompt feedback!

            Yes, I am aware of the "personal" burndowns - we have configured our instance to cater for this.

            Looking forward to 5.2

            Tadhg Tadhg added a comment - @JC That is great news - many thanks for the prompt feedback! Yes, I am aware of the "personal" burndowns - we have configured our instance to cater for this. Looking forward to 5.2

            JC added a comment - - edited

            @Tadhg
            Yep that is exactly what the Agile Gadget based on filters will be computing.
            Now in the current version of GreenHopper there are no ways of changing the start nor the end date. This will now be possible in the next GreenHopper release (5.2)

            Now be careful when computing "personal" hour burndowns.
            The data is based on who is the "current" assignee not who logged work on the issues.

            Cheers,
            JC

            JC added a comment - - edited @Tadhg Yep that is exactly what the Agile Gadget based on filters will be computing. Now in the current version of GreenHopper there are no ways of changing the start nor the end date. This will now be possible in the next GreenHopper release (5.2) Now be careful when computing "personal" hour burndowns. The data is based on who is the "current" assignee not who logged work on the issues. Cheers, JC

            JC added a comment -

            Computed dates can now be changed by the users.

            JC added a comment - Computed dates can now be changed by the users.

            Tadhg Tadhg added a comment -

            Cross Project Burndowns

            Introduction

            This comment outlines Cross Project Burndowns (CPB) from my perspective, and this functionality would need to be provided for CPBs to be of use.

            Overview

            Burndowns are a key feature of monitoring the current sprint. Once the sprint is complete, they are snapshotted for posterity. This is how Burndowns currently work in Greenhopper.

            If we agree with this assertion, then CPBs would also be used for monitoring the current sprints for projects.

            CPBs would typically be used in organisation where there are multiple concurrent projects that share some resources across those projects.

            For example, if developer Sally is working concurrently on the current sprints for Project A and Project B, a CPB for Sally would be a union of her current burndown for Project A and her current burndown for Project B.

            If a CPB cannot produce the exact union – then they are of no use in this situation.

            Example

            If Sally is working on the following current sprints:

            • Project 1 – Sprint 2 (P1.2)
            • Project2 – Sprint 4 (P2.4)

            And her individual burndowns in Greenhopper shows:

            • P1.2
              • Mon: 4 hours remaining
              • Tue: 3 hours remaining
              • Wed: 7 hours remaining
            • P2.4
              • Mon: 1 hours remaining
              • Tue: 12 hours remaining
              • Wed: 5 hours remaining

            Then a CPB with the following criteria:

            • Start Date: Mon
            • End Date: Wed
            • Developer: Sally
            • Project & Fix Version = P1.2 OR Project & Fix Version = 2.4

            Should produce the exact union:

            • Sally and (P1.2 or P2.4)
              • Mon: (4 + 1) = 5 hours remaining
              • Tue: (3 + 12) = 15 hours remaining
              • Wed: (7 + 5) = 12 hours remaining

            Can this be confirmed?

            Tadhg Tadhg added a comment - Cross Project Burndowns Introduction This comment outlines Cross Project Burndowns (CPB) from my perspective, and this functionality would need to be provided for CPBs to be of use. Overview Burndowns are a key feature of monitoring the current sprint. Once the sprint is complete, they are snapshotted for posterity. This is how Burndowns currently work in Greenhopper. If we agree with this assertion, then CPBs would also be used for monitoring the current sprints for projects. CPBs would typically be used in organisation where there are multiple concurrent projects that share some resources across those projects. For example, if developer Sally is working concurrently on the current sprints for Project A and Project B, a CPB for Sally would be a union of her current burndown for Project A and her current burndown for Project B. If a CPB cannot produce the exact union – then they are of no use in this situation. Example If Sally is working on the following current sprints: Project 1 – Sprint 2 (P1.2) Project2 – Sprint 4 (P2.4) And her individual burndowns in Greenhopper shows: P1.2 Mon: 4 hours remaining Tue: 3 hours remaining Wed: 7 hours remaining P2.4 Mon: 1 hours remaining Tue: 12 hours remaining Wed: 5 hours remaining Then a CPB with the following criteria: Start Date: Mon End Date: Wed Developer: Sally Project & Fix Version = P1.2 OR Project & Fix Version = 2.4 Should produce the exact union: Sally and (P1.2 or P2.4) Mon: (4 + 1) = 5 hours remaining Tue: (3 + 12) = 15 hours remaining Wed: (7 + 5) = 12 hours remaining Can this be confirmed?

            Tadhg Tadhg added a comment -

            It would be awesome to have this fixed - CrossProject burndowns (with configurable Start & End dates - (as per Sprints)) are very powerful!

            Tadhg Tadhg added a comment - It would be awesome to have this fixed - CrossProject burndowns (with configurable Start & End dates - (as per Sprints)) are very powerful!

            Tadhg Tadhg added a comment -

            I agree that this is a Major Defect. The Agile Gadget for CrossProject Burndown charts is effectively unusable (for us) without this fix.

            The Start Date and End Date should be allowed to be set manually, to allow the CrossProject Burndown to reflect the same dates as in the individual project burndowns.

            Tadhg Tadhg added a comment - I agree that this is a Major Defect. The Agile Gadget for CrossProject Burndown charts is effectively unusable (for us) without this fix. The Start Date and End Date should be allowed to be set manually, to allow the CrossProject Burndown to reflect the same dates as in the individual project burndowns.

            Rickard Schoultz added a comment -

            I actually think this is quite a major defect. Can the issue be updated?
            Does anyone know about a workaround - is there any logic to how can you control start and end date of the agile gadget?

            Rickard Schoultz added a comment - I actually think this is quite a major defect. Can the issue be updated? Does anyone know about a workaround - is there any logic to how can you control start and end date of the agile gadget?

            Rickard Schoultz added a comment -

            Besides the linked issue GHS-2091, we have also experienced the same problem for cross-burn down projects as you mention.

            Rickard Schoultz added a comment - Besides the linked issue GHS-2091 , we have also experienced the same problem for cross-burn down projects as you mention.

            Dominik Haag added a comment -

            This issue was created after I raised a support-request. In my opinion this is a bug and not a new feature. If you treat that as a new feature, you have to remove the description of cross-project burndown here http://confluence.atlassian.com/display/GH/Using+the+Agile+Gadget#UsingtheAgileGadget-ConfiguringtheAgileGadgettodisplayCrossProjectBurndownCharts

            Dominik Haag added a comment - This issue was created after I raised a support-request. In my opinion this is a bug and not a new feature. If you treat that as a new feature, you have to remove the description of cross-project burndown here http://confluence.atlassian.com/display/GH/Using+the+Agile+Gadget#UsingtheAgileGadget-ConfiguringtheAgileGadgettodisplayCrossProjectBurndownCharts

              Unassigned Unassigned
              aatkins TonyA
              Votes:
              4 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: