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

Get Sprint information for Issues assigned to planned (not started) Sprints

    • 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 new planning board is great and solves many of our cross project type of problems. Thank you very much! However when using the new view we divide out backlogs into sprints instead of dividing the backlog using different versions in the classic planning board. The new view is much more easy to work with especially the simplicity to do re-planning (change sprint velocity) just by dragging and dropping the bottom part of the sprint boxes. However we lost one very important thing moving from Fix-version to the new artifact “Sprint” and that is the visibility of the future plan of a backlog items.

      Problem
      When requesting information about an Issue (User Story), the Agile Panel on the issue view page contains information regarding only the started or completed sprints in which the issue has been planned. For us and I do think for others as well it is crucial to know when an Issue (User Story) has been planned in the future.

      Feature request
      We really need to be able to be able to find out the name of a sprint to which and Issue have been assign even though the sprint is not yet started. The information is needed both in the issue browser view and in the REST API.

      Thank you,
      Petru

        1. 1.png
          1.png
          65 kB
        2. planned_sprints_search.png
          planned_sprints_search.png
          29 kB

          Form Name

            [JSWSERVER-6036] Get Sprint information for Issues assigned to planned (not started) Sprints

            Hi All,

            Many thanks for your votes and comments on this issue, I wanted to provide an update: this is now fully implemented as of JIRA Agile 6.3. Sprints are no longer mere markers in the backlog (they actually contain issues), and you can query them by using "sprint = " JQL. Read more on our release notes: https://confluence.atlassian.com/display/AGILE/JIRA+Agile+6.3+Release+Notes

            Kind regards

            Tom Kotecki
            Product Manager, JIRA Agile

            Tom Kotecki (Inactive) added a comment - Hi All, Many thanks for your votes and comments on this issue, I wanted to provide an update: this is now fully implemented as of JIRA Agile 6.3. Sprints are no longer mere markers in the backlog (they actually contain issues), and you can query them by using "sprint = " JQL. Read more on our release notes: https://confluence.atlassian.com/display/AGILE/JIRA+Agile+6.3+Release+Notes Kind regards Tom Kotecki Product Manager, JIRA Agile

            Hi Michael,

            I've just tested this out and it seems to be exactly what we needed!

            Thanks,
            Petru

            Petru Dumuta added a comment - Hi Michael, I've just tested this out and it seems to be exactly what we needed! Thanks, Petru

            Hi everyone,

            Please note that the "Agile Issue Panel" part of this story has been implemented as of JIRA Agile 6.3. You can now see when issues are assigned to future sprints.

            Please let us know what you think.

            Regards,
            JIRA Agile Team

            Michael Tokar added a comment - Hi everyone, Please note that the "Agile Issue Panel" part of this story has been implemented as of JIRA Agile 6.3. You can now see when issues are assigned to future sprints. Please let us know what you think. Regards, JIRA Agile Team

            Preliminarily assigning stories to upcoming sprints is a key feature that our POs do to clarify their backlog and do cross-team synchronization. So defining the names and dates for upcoming sprints together with the ability to assign stories to those is key. All this is no problem when using FixVersion in Classic Mode. Without these options, the new RapidBoards will not be acceptable by our teams.

            Meino von Spreckelsen added a comment - Preliminarily assigning stories to upcoming sprints is a key feature that our POs do to clarify their backlog and do cross-team synchronization. So defining the names and dates for upcoming sprints together with the ability to assign stories to those is key. All this is no problem when using FixVersion in Classic Mode. Without these options, the new RapidBoards will not be acceptable by our teams.

            We really need the upcoming sprints to be associated with the Sprint custom field. Then we can do something like "Sprint in futureSprint()"

            Viðar Svansson [Tempo] added a comment - We really need the upcoming sprints to be associated with the Sprint custom field. Then we can do something like "Sprint in futureSprint()"

            Our release manager as well as our level 2 support team wants to be able to check if a story or defect is scheduled in a sprint across 50+ boards, so unfortunately Scriptrunner does not help here (I cannot even write a custom JQL function, because GH code does not store the upcomming sprints in a format that can be queried (yet))

            Fabian Meier added a comment - Our release manager as well as our level 2 support team wants to be able to check if a story or defect is scheduled in a sprint across 50+ boards, so unfortunately Scriptrunner does not help here (I cannot even write a custom JQL function, because GH code does not store the upcomming sprints in a format that can be queried (yet))

            Edwin Stol added a comment -

            fabian9; As a work-around, i would suggest selecting the stories in the upcoming sprint (with CTRL/SHIFT+click), right mousebutton, view in issue navigator.
            Or Jamie Echlin's excellent Script Runner plug-in, but you can't use that if you're an OnDemand customer.

            Edwin Stol added a comment - fabian9 ; As a work-around, i would suggest selecting the stories in the upcoming sprint (with CTRL/SHIFT+click), right mousebutton, view in issue navigator. Or Jamie Echlin's excellent Script Runner plug-in, but you can't use that if you're an OnDemand customer.

            I am trying to search for issues that are in future sprints but GH does not allow to do that:

            sprint in openSprints()
            

            Only finds issues that are in an active sprint.

            sprint not in openSprints()
            

            Finds all issues from former and future sprints.

            I am asking for a query that returns all issues that associated to planned sprints. After some more research, it turns out that they actually have no value for the Sprint custom field associated and future planned sprints are defined via a marker value. Thus it will be difficult to identify the issues associated with them. Please discuss the matter with a developer and let us know if there is a way to identify them. A workaround would be acceptable.

            This screenshot should clarify what we want to achieve:

            In addition, there seems to be not ability to search for scope changes (e.g. to easily find / report how much teams have added after the sprint started or to e.g. calculate how much of their original commitment they have achieved.

            Fabian Meier added a comment - I am trying to search for issues that are in future sprints but GH does not allow to do that: sprint in openSprints() Only finds issues that are in an active sprint. sprint not in openSprints() Finds all issues from former and future sprints. I am asking for a query that returns all issues that associated to planned sprints. After some more research, it turns out that they actually have no value for the Sprint custom field associated and future planned sprints are defined via a marker value. Thus it will be difficult to identify the issues associated with them. Please discuss the matter with a developer and let us know if there is a way to identify them. A workaround would be acceptable. This screenshot should clarify what we want to achieve: In addition, there seems to be not ability to search for scope changes (e.g. to easily find / report how much teams have added after the sprint started or to e.g. calculate how much of their original commitment they have achieved.

            futureSprint() does not cover our needs. We need to associate data with the future sprints and they are only available as markers. This is a major functionality missing that we had previously when planning on versions and breaks our integration story with GH.

            We haven't found a way to connect old markers with new sprints so there is no way for us to represent them as a single entity. Are we missing something obvious? If this is not possible, could you add one of the suggestion solutions (or maybe you have a better solution):

            1. Assign the ID of the marker to the sprint ID.
            2. Include the marker ID in the sprint entity.
            3. Fire an event (and webhook) when sprint is created, containing rapid id, marker id, and sprint id.

            Viðar Svansson [Tempo] added a comment - futureSprint()  does not cover our needs. We need to associate data with the future sprints and they are only available as markers. This is a major functionality missing that we had previously when planning on versions and breaks our integration story with GH. We haven't found a way to connect old markers with new sprints so there is no way for us to represent them as a single entity. Are we missing something obvious? If this is not possible, could you add one of the suggestion solutions (or maybe you have a better solution): 1. Assign the ID of the marker to the sprint ID. 2. Include the marker ID in the sprint entity. 3. Fire an event (and webhook) when sprint is created, containing rapid id, marker id, and sprint id.

            I like the idea of a futureSprint() function we could use to further analyze sprint content before we commit to it. Existing reports and gadgets could be used to answer questions about that sprint might look like (along the lines of GHS-5774) - helping us to know when we're about to overcommit based on a scarce resource at a more granular level than what Greenhopper will currently tell us.

            Charles Albrecht added a comment - I like the idea of a futureSprint() function we could use to further analyze sprint content before we commit to it. Existing reports and gadgets could be used to answer questions about that sprint might look like (along the lines of GHS-5774 ) - helping us to know when we're about to overcommit based on a scarce resource at a more granular level than what Greenhopper will currently tell us.

              Unassigned Unassigned
              petru.dumuta Petru Dumuta
              Votes:
              20 Vote for this issue
              Watchers:
              19 Start watching this issue

                Created:
                Updated:
                Resolved: