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

As a project manager I can compare the scope against a baseline

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Fixed
    • 6.0
    • 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.

      Greenhopper calculates scope of a version based on the issues that are related to a version.
      This is very handy to visualize scope increase (or decrease) using the chart board.

      What is missing is the concept of a baseline, so that you can compare the
      scope against what was initially committed to.

      When we are running a sprint we do 'in-flight replanning' meaning that we are moving
      some stories back to the product backlog because other stories are taking more
      time, or because stories are 'below the line'

      At the end of the sprint, I'm getting questions like 'at the start of the sprint
      we had initially 520hours committed, but the current graphs shows only 460 hours'

      At that moment it would be very useful to be able to show:
      This is the list of issues we took initally in the iteration, and these have been dropped
      'in-flight', to be able to deliver the other priorities, or the way around,
      'during this sprint following stories have been added to the iteration'

            [JSWSERVER-1815] As a project manager I can compare the scope against a baseline

            Shaun Clowes (Inactive) added a comment -

            Hi All,

            The reports in the new GreenHopper boards support this requirement:

            • The burndown chart will show issues added and removed after the sprint began
            • The Sprint Report will list all issues added and removed after the sprint began

            Thanks,
            Shaun

            Shaun Clowes (Inactive) added a comment - Hi All, The reports in the new GreenHopper boards support this requirement: The burndown chart will show issues added and removed after the sprint began The Sprint Report will list all issues added and removed after the sprint began Thanks, Shaun

            Jan De Geeter added a comment -

            I would like to generalise this requirement: Greenhopper should never change past datapoints in the charts. An agile team takes a daily commitment on the scope, not only at the start of the sprint. If implemented this way, the total hours or total number of issues always reflects the scope at that day. Scope changes will manifest itself as jumps in that total.
            This may not be easy to implement efficiently, as this will force Greenhopper to search for all issues that once had a certain fix version between the start and end date of a sprint.

            Jan De Geeter added a comment - I would like to generalise this requirement: Greenhopper should never change past datapoints in the charts. An agile team takes a daily commitment on the scope, not only at the start of the sprint. If implemented this way, the total hours or total number of issues always reflects the scope at that day. Scope changes will manifest itself as jumps in that total. This may not be easy to implement efficiently, as this will force Greenhopper to search for all issues that once had a certain fix version between the start and end date of a sprint.

            Steve Lane added a comment -

            This seems somewhat related to GHS-1288.

            Steve Lane added a comment - This seems somewhat related to GHS-1288 .

            Ryan O'Sullivan added a comment -

            This is an important feature to consider and would make management of scope much easier. Baselining is important in this scenario. It is also vitally important accros releases

            Ryan O'Sullivan added a comment - This is an important feature to consider and would make management of scope much easier. Baselining is important in this scenario. It is also vitally important accros releases

              Unassigned Unassigned
              da0b846da3a7 francis
              Votes:
              19 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: