-
Suggestion
-
Resolution: Unresolved
-
3
-
2
-
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
- Create multiple Sprints in JIRA for teams (Team A = A1, A2, A3, Team B = B1, B2, B3, ...)
- Start the first round of Sprints (A1, B1, C1, D1)
- Use the Board as your Issue source
- 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.
- is related to
-
JRACLOUD-88462 Sprints can appear out of order when multiple issue sources contain the same sprint
-
- Closed
-
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)