Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-90831

Ability to have one sprint active per Agile board even if they are in the same project

XMLWordPrintable

    • 5
    • 9
    • Hide
      Atlassian Status as at 27 January 2016

      Please see comment below

      Kind regards,
      Martin
      JIRA Software

      Additional information

      At the moment, our recommended configuration for multiple teams working off the same backlog is to have separate boards for each team (using mutually exclusive filters such as "project = x and component = TeamA" and "project = x and component = TeamB") then a parent board that includes all of the issues in the child boards (with a filter such as "project = x"). In this configuration the two children boards can rank and execute sprints completely independently while the parent board will see all of the sprint information from the sub boards.

      However, we do understand the need for multiple teams to be able to work from a single board. In the future we would like to address this by providing a team concept so that sprints and issues can be marked with a particular team. However, in the mean time we have implemented the ability to have multiple sprints active on a single board by enabling the parallel sprints feature. When the feature is enabled multiple sprints can be started on the same board, the sprints can be filtered easily on work mode and you can choose which sprint to finish when closing out a sprint.

      Show
      Atlassian Status as at 27 January 2016 Please see comment below Kind regards, Martin JIRA Software Additional information At the moment, our recommended configuration for multiple teams working off the same backlog is to have separate boards for each team (using mutually exclusive filters such as "project = x and component = TeamA" and "project = x and component = TeamB") then a parent board that includes all of the issues in the child boards (with a filter such as "project = x"). In this configuration the two children boards can rank and execute sprints completely independently while the parent board will see all of the sprint information from the sub boards. However, we do understand the need for multiple teams to be able to work from a single board. In the future we would like to address this by providing a team concept so that sprints and issues can be marked with a particular team. However, in the mean time we have implemented the ability to have multiple sprints active on a single board by enabling the parallel sprints feature. When the feature is enabled multiple sprints can be started on the same board, the sprints can be filtered easily on work mode and you can choose which sprint to finish when closing out a sprint.

    • 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.

      Our development teams are separated into pods. Each of these pods are working on a different release simultaneously. The limitation that you can only have one sprint active per project limits the use of rapid board for our teams.

            [JRACLOUD-90831] Ability to have one sprint active per Agile board even if they are in the same project

            abi821075989 added a comment -

            Hi there, 
            We have successfully created an Add-on that solves for this. We had the same issues with managing multiple projects and teams using different boards. Please feel free to try and provide your feedback. 

            Link:
            https://marketplace.atlassian.com/plugins/early-bird-planner-prod/cloud/overview

            abi821075989 added a comment - Hi there,  We have successfully created an Add-on that solves for this. We had the same issues with managing multiple projects and teams using different boards. Please feel free to try and provide your feedback.  Link: https://marketplace.atlassian.com/plugins/early-bird-planner-prod/cloud/overview

            Aaron added a comment -

            Our need does match the title and is: Multiple teams each with their own board. These boards span multiple projects, with overlap between the teams on the projects. Because of the way sprints currently work, the sprint from one Team shows up in the other Teams boards.

            Aaron added a comment - Our need does match the title and is: Multiple teams each with their own board. These boards span multiple projects, with overlap between the teams on the projects. Because of the way sprints currently work, the sprint from one Team shows up in the other Teams boards.

            Martin (Inactive) added a comment - - edited

            The summary of this Suggestion does not seem to match its description and comment thread and I assume this was a typo when originally created.
            I seems that
            As a scrum master I would like to be able to have one sprint active per rapid board even if they are in the same project
            was meant to be
            As a scrum master I would like to be able to have more than one sprint active per rapid board even if they are in the same project

            Note that this was recently shortened by myself from
            As a scrum master I would like to be able to have one sprint active per rapid board even if they are in the same project
            to
            Ability to have one sprint active per Agile board even if they are in the same project
            which does not change the relevant part of the summary.

            Given this, it would seem that the Parallel Sprint feature is all that is required to satisfy the requests here.

            The Parallel Sprints feature has now moved from JIRA Software Labs to a configuration option in JIRA Software Cloud (since 11 Jan 2016), please see https://confluence.atlassian.com/display/JIRASOFTWARECLOUD/Using+Parallel+Sprints

            This change will also be shipped in the next 7.x version of JIRA Software Server. For further progress please follow https://jira.atlassian.com/browse/GHS-11123

            A related request for Parallel Sprints to be a board setting rather than a global setting can be tracked at https://jira.atlassian.com/browse/GHS-12588

            Kind regards,
            Martin
            JIRA Software

            Martin (Inactive) added a comment - - edited The summary of this Suggestion does not seem to match its description and comment thread and I assume this was a typo when originally created. I seems that As a scrum master I would like to be able to have one sprint active per rapid board even if they are in the same project was meant to be As a scrum master I would like to be able to have more than one sprint active per rapid board even if they are in the same project Note that this was recently shortened by myself from As a scrum master I would like to be able to have one sprint active per rapid board even if they are in the same project to Ability to have one sprint active per Agile board even if they are in the same project which does not change the relevant part of the summary. Given this, it would seem that the Parallel Sprint feature is all that is required to satisfy the requests here. The Parallel Sprints feature has now moved from JIRA Software Labs to a configuration option in JIRA Software Cloud (since 11 Jan 2016), please see https://confluence.atlassian.com/display/JIRASOFTWARECLOUD/Using+Parallel+Sprints This change will also be shipped in the next 7.x version of JIRA Software Server. For further progress please follow https://jira.atlassian.com/browse/GHS-11123 A related request for Parallel Sprints to be a board setting rather than a global setting can be tracked at https://jira.atlassian.com/browse/GHS-12588 Kind regards, Martin JIRA Software

            vincentj added a comment -

            Our teams just ran into the same issue, although we want separate teams to have separate boards with separate filters that aren't necessarily fully exclusive. It's crazy that having multiple separate teams that share one project/component is so difficult to manage, especially since other tools I've used do this just fine.

            https://answers.atlassian.com/questions/33142331/cant-start-my-sprint-because-of-another-teams-active-sprint

            vincentj added a comment - Our teams just ran into the same issue, although we want separate teams to have separate boards with separate filters that aren't necessarily fully exclusive. It's crazy that having multiple separate teams that share one project/component is so difficult to manage, especially since other tools I've used do this just fine. https://answers.atlassian.com/questions/33142331/cant-start-my-sprint-because-of-another-teams-active-sprint

            Christopher Penkin added a comment -

            I see this issue is an old one. Are there plans or not to implement this?

            Thanks.

            Christopher Penkin added a comment - I see this issue is an old one. Are there plans or not to implement this? Thanks.

            Laurence Tuot added a comment -

            Hi Atlassian,
            Is there any plan to develop this feature ? This is causing a lot of issues for our dev teams here.

            Laurence Tuot added a comment - Hi Atlassian, Is there any plan to develop this feature ? This is causing a lot of issues for our dev teams here.

            Viet Ta added a comment -

            Vote up for this feature.

            Viet Ta added a comment - Vote up for this feature.

            David Vega added a comment -

            This is really needed for matrix organizations

            David Vega added a comment - This is really needed for matrix organizations

            MattD added a comment -

            My approach to this with 6.2 is to have a select custom field named Team and to create Swimlanes based on Team=TeamA, Team=TeamB etc. Card coloring by Team also helps plus Quick Filters. That gives me multiple ways to focus on a single team in a board. Still this is for a single sprint.

            MattD added a comment - My approach to this with 6.2 is to have a select custom field named Team and to create Swimlanes based on Team=TeamA, Team=TeamB etc. Card coloring by Team also helps plus Quick Filters. That gives me multiple ways to focus on a single team in a board. Still this is for a single sprint.

            John Telford added a comment -

            Just adding a note here for if/when this gets picked up for future use with a couple of our use cases for overlapping sprints. In our world, every code change is tied to a JIRA card and every release is tied to a sprint. If it doesn't have a sprint, it doesn't have a release.

            Use Case 1: Sprint "done", regression uncovers bug that needs to be fixed
            -Scenario
            --Sprint 1 ends on Thursday 1/15 and releases on Tuesday 1/20
            --Sprint 2 starts on Friday 1/16
            --Sprint 1 is "complete" but on Monday 1/19 we uncover an issue that needs to be resolved (ISS-10) before golive. This occasionally happens with regression testing or something slipped through. We leave Sprint 1 open so that a developer can go in an make the fix via an issue in Sprint 1. They won't get credit for it in the burndown of Sprint 1 or Sprint 2 (which I don't have a problem with) but if we are forced to close Sprint 1 before we start Sprint 2 things become a mess. If ISS-10 is created as a card in Sprint 2, it is not really true because the code change will go out with Sprint 1.

            Use Case 2: Hotfix
            -Scenario we are in the midst of Sprint 20 and an unscheduled release is identified
            -Let's say we just released Sprint 19 and are in the midst of Sprint 20 and an issue crops up that requires a deploy. What we do on the classic boards is go in and create Sprint 19.1 that will contain the issues for the hot fix. This minisprint may only live for one day but all of the issues for the release will have a sprint.

            In both of the above examples, the sprint teams won't get credit for the cards in their current sprint (which I am fine with because this averages out over time and is why velocity is never 100% of available time) and we know that.

            The Parallel Sprints feature seems like it should allow everything to work correctly for us but when that feature is disabled, I wanted to provide some use cases to help in crafting a longer term solution.

            John Telford added a comment - Just adding a note here for if/when this gets picked up for future use with a couple of our use cases for overlapping sprints. In our world, every code change is tied to a JIRA card and every release is tied to a sprint. If it doesn't have a sprint, it doesn't have a release. Use Case 1: Sprint "done", regression uncovers bug that needs to be fixed -Scenario --Sprint 1 ends on Thursday 1/15 and releases on Tuesday 1/20 --Sprint 2 starts on Friday 1/16 --Sprint 1 is "complete" but on Monday 1/19 we uncover an issue that needs to be resolved (ISS-10) before golive. This occasionally happens with regression testing or something slipped through. We leave Sprint 1 open so that a developer can go in an make the fix via an issue in Sprint 1. They won't get credit for it in the burndown of Sprint 1 or Sprint 2 (which I don't have a problem with) but if we are forced to close Sprint 1 before we start Sprint 2 things become a mess. If ISS-10 is created as a card in Sprint 2, it is not really true because the code change will go out with Sprint 1. Use Case 2: Hotfix -Scenario we are in the midst of Sprint 20 and an unscheduled release is identified -Let's say we just released Sprint 19 and are in the midst of Sprint 20 and an issue crops up that requires a deploy. What we do on the classic boards is go in and create Sprint 19.1 that will contain the issues for the hot fix. This minisprint may only live for one day but all of the issues for the release will have a sprint. In both of the above examples, the sprint teams won't get credit for the cards in their current sprint (which I am fine with because this averages out over time and is why velocity is never 100% of available time) and we know that. The Parallel Sprints feature seems like it should allow everything to work correctly for us but when that feature is disabled, I wanted to provide some use cases to help in crafting a longer term solution.

              Unassigned Unassigned
              d042d064de91 Micah Figone
              Votes:
              186 Vote for this issue
              Watchers:
              119 Start watching this issue

                Created:
                Updated: