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

      Summary

      Advanced Roadmaps is incapable of accurately scheduling future Sprints when running parallel with multiple Teams at once. With multiple Teams running multiple Sprints at once, the scheduler doesn't align the upcoming Sprints unless there's a start/end date added which isn't possible for future Sprints.

      Steps to Reproduce

      1. Create multiple Sprints in JIRA for teams (Team A = A1, A2, A3, Team B = B1, B2, B3, ...)
      2. Start the first round of Sprints (A1, B1, C1, D1)
      3. Use the Board as your Issue source
      4. Create teams based on the Sprints (Team A, Team B, ...) and set sprint duration (e.g. 3 weeks)

      Expected Results

      When grouping the view settings to Teams, each team is presented with their current active Sprints and upcoming Sprints, following each other chronologically according to the Team's Sprint iteration length and capacity.

      Actual Results

      All future Sprints are scheduled with the same dates across all teams regardless of the Team's iteration or capacity.

      Workaround

      • Create a filter for each team that extracts only the tickets for this team
      • Optionally you can create a board in the project for each of these filters which can be convenient for each team to see only their tickets
      • Instead of using the project board as the issue source for the plan, create one issue source for each team board
      • In the plan, edit each team to associate it with the corresponding issue source

      Now the scheduler will be able to plan the work of the different teams in parallel.

            [JRACLOUD-88189] Parallel Sprints scheduling with multiple teams

            Felix Rohrbach added a comment - - edited

            An addition to "Actual Results" should be that all future sprints are queued up sequentially, even though they will be worked on in parallel. This means that if an issue is already assigned to an upcoming sprint, the timeline will show a wrong start/end date for that issue.

            Also "workaround" expects that all issues are assigned to a team. In my case all teams share the same backlog and I assign the issues to the teams based on the timeline and the teams forecasted load.... (which of course is currently not possible to see)

            Felix Rohrbach added a comment - - edited An addition to "Actual Results" should be that all future sprints are queued up sequentially, even though they will be worked on in parallel. This means that if an issue is already assigned to an upcoming sprint, the timeline will show a wrong start/end date for that issue. Also "workaround" expects that all issues are assigned to a team. In my case all teams share the same backlog and I assign the issues to the teams based on the timeline and the teams forecasted load.... (which of course is currently not possible to see)

            I already have my plan configured as the workaorund suggests and I the information in the scheduler is still incorrect. 

            One team per one board as the issue source, and parallel sprints are out of order. 

            Courtney M. Schkurko added a comment - I already have my plan configured as the workaorund suggests and I the information in the scheduler is still incorrect.  One team per one board as the issue source, and parallel sprints are out of order. 

              Unassigned Unassigned
              lellis2@atlassian.com Belto
              Votes:
              27 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated: