Uploaded image for project: 'Jira Software Cloud'
  1. Jira Software Cloud
  2. JSWCLOUD-12196

Split an issue and its story points into parts whilst maintaining state

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Fixed
    • None
    • Hide
      Atlassian Status as at Nov 2016
      Show
      Atlassian Status as at Nov 2016 This feature is now available in JIRA Software Cloud. https://confluence.atlassian.com/jirasoftwarecloud/using-your-scrum-backlog-764478062.html
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      We strictly use Fibonacci story point values by the book. When the development team is working on an issue we encourage them to break it down into smaller pieces for their work and to give a more granular burn-down but without impacting the committed-to volume of the agreed whole. Presently the clone function is used for this but then further tweaking is required to adjust the story points of the clones and original issue. This causes some noise on the burndown chart and in the respective reports this looks like lots of scope change events but it isn't - it's scope neutral. Also the clones don't inherit the original's workflow state of, in our case, "commissioned".
      We would very much appreciate the possibility of a "split" function, which would provide a dialog box to enter a summary for each of the new issues, inclusive of the original. It should also be possible to enter directly in that dialog the Story Points which each of the new issues, including the original, should have. This must total the same as the story points of the original. On pressing OK, the new issues would be created and the original adjusted in its summary and story point value. All issues created should automatically have the same state and assignee (as well as other meta data such as components, labels, sprint etc.) as the original did prior to the split. All of this should be registered as a single split action on the reports and be completely invisible on the burndown chart.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              1287cb9eb98f Ian Catley
              Votes:
              3 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: