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.

            Hi Shaun,

            Thanks for the fast reply! The new GH board with the artifact “Sprint” does replace the previous “Version” based sprint divider. The bad thing with the old way is just that, it was really cumbersome to do re-planning of the backlog when sprint velocities changed and the content of ~5-10 sprints needs to be pushed forward. The new board solves that problem perfectly with the drag and drop feature of the content in sprints. Looking at Scrum from a sales/commitment point-of-view one important part is the release planning based on the backlog and sprint velocity, e.g. a product owner need to be able to answer delivery date questions in ways such as: “Based on the current team velocity and the current backlog priority your feature X will start to be implemented in three sprints and ready within 4 sprints…”.

            With only one team backlog we can just look at the Plan-view of the board but a normal situation for us is that a customer feature requires work done by many teams and hence distributed over several team-backlogs. This is the reason why we would like to be able to ask an Issue, “In what sprint are you?”. The name of the sprint is suffixed with the start/end-week numbers so if we have a top-level customer requirement and it is broken down in many user stories distributed over multiple backlogs it would be excellent to be able to see the assigned sprint names in the issue browser for each user story.

            Thanks,
            Petru

            Petru Dumuta added a comment - Hi Shaun, Thanks for the fast reply! The new GH board with the artifact “Sprint” does replace the previous “Version” based sprint divider. The bad thing with the old way is just that, it was really cumbersome to do re-planning of the backlog when sprint velocities changed and the content of ~5-10 sprints needs to be pushed forward. The new board solves that problem perfectly with the drag and drop feature of the content in sprints. Looking at Scrum from a sales/commitment point-of-view one important part is the release planning based on the backlog and sprint velocity, e.g. a product owner need to be able to answer delivery date questions in ways such as: “Based on the current team velocity and the current backlog priority your feature X will start to be implemented in three sprints and ready within 4 sprints…”. With only one team backlog we can just look at the Plan-view of the board but a normal situation for us is that a customer feature requires work done by many teams and hence distributed over several team-backlogs. This is the reason why we would like to be able to ask an Issue, “In what sprint are you?”. The name of the sprint is suffixed with the start/end-week numbers so if we have a top-level customer requirement and it is broken down in many user stories distributed over multiple backlogs it would be excellent to be able to see the assigned sprint names in the issue browser for each user story. Thanks, Petru

            Hi petru.dumuta,

            Just to clarify, the future sprints shown in the backlog do not actually exist yet, that is, they're not real sprints and none of the issues shown inside that 'potential' sprint have been modified in any way. As a result there is no JQL way to query anything about the issues because nothing has been changed. The future sprints you see in the backlog are actually just 'ranked' items, they are stored in the linked list of all of the issues in the system that represents rank.

            In the future we could potentially do something in the issue navigator like "project = x and rank > futureSprint("Future Sprint 1", "Board Name") and rank < futureSprint("Future Sprint 2", "Board Name")" but we're unlikely to be able to implement this specific feature (i.e a REST endpoint or showing the information directly in the JIRA view issue page).

            Thanks,
            Shaun

            Shaun Clowes (Inactive) added a comment - Hi petru.dumuta , Just to clarify, the future sprints shown in the backlog do not actually exist yet, that is, they're not real sprints and none of the issues shown inside that 'potential' sprint have been modified in any way. As a result there is no JQL way to query anything about the issues because nothing has been changed. The future sprints you see in the backlog are actually just 'ranked' items, they are stored in the linked list of all of the issues in the system that represents rank. In the future we could potentially do something in the issue navigator like "project = x and rank > futureSprint("Future Sprint 1", "Board Name") and rank < futureSprint("Future Sprint 2", "Board Name")" but we're unlikely to be able to implement this specific feature (i.e a REST endpoint or showing the information directly in the JIRA view issue page). Thanks, Shaun

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

                Created:
                Updated:
                Resolved: