Grouping by teams
When you group issues by teams, the issues will be displayed in team-specific swimlanes. The teams in the plan have their own swimlanes, and you can view its assigned issues by expanding each team.
If you've associated the teams in your plan to corresponding issue sources, you can also choose to show the overall capacity of these teams in the timeline. This can help you visualize how team-specific work is distributed across multiple sprints.
| 1 | One of the initiative issues that's assigned to the IOS app team in the plan |
| 2 | One of the parallel sprints assigned to the team, and this sprint is currently active |
| 3 | Another parallel sprint assigned to the team, and this sprint is also currently active |
| 4 |
|
| 5 | Other sprints belonging to the team, including the ones that have already been created in Jira, and the ones allocated as future sprints in the timeline |
To group issues by teams:
- In the roadmap view of the plan, click View settings.
- From the 'Group by' menu, choose Team. The issues in the plan will be grouped into team-specific swimlanes.
- To display the sprints associated to teams in the plan, click the Show capacity on timeline checkbox.
Notes on showing sprints and capacity in a plan:
- All the sprints associated with a team will appear in the timeline, which means your timeline might be filled with a lot of sprints, and might end up too crowded. To handle this, consider viewing issues for just a specific timeframe.
- When a sprint is completed, the sprint will be visualized on the timeline as finishing at the end of the day before it was completed. Effectively, this prevents sprints from appearing to overlap on the timeline. This visualization applies whether your issues are scheduled through sprint assignment, or you're manually scheduling the issues themselves.
- If your teams are working on parallel sprints in Jira, these sprints will appear independently in the timeline.
Showing capacity in the timeline
As already mentioned, you can show the overall capacity of the teams in the timeline. This can help you visualize how team-specific work is distributed across multiple sprints or iterations, and ultimately determine if too much work has been scheduled for a sprint or iteration.
Samples of healthy and unhealthy sprints
In the above example, clicking the capacity bar of a sprint will display the capacity details which may include:
- The start and end dates of the sprint
- The status of the sprint, whether it's an active, future, or projected sprint
- The percentage of issues that have been completed
- With the default velocity set to 30 story points, the percentage of how full the sprint is in terms of the estimated story points. If the team is estimating issues in hours or days, this will reflect in the percentage accordingly.
- The number of unestimated issues in the sprint
The Dingo sprint is showing a red capacity bar, which means too much work has been allocated to that sprint. With this visual indicator in the timeline, you can then quickly consider how to fix this up — either by removing some issues from that sprint, or adding more people to the corresponding team.
Understanding capacity details in Scrum and Kanban
For both Scrum and Kanban teams, the capacity bars reflect how work is evenly distributed across the corresponding duration (sprints for Scrum, iterations for Kanban). This is the basic premise on how work is distributed in the current plans.
There are some differences to note about how bars reflect capacity details however.
For Scrum teams:
- When using story point estimates, velocity is measured against the sprint duration. If velocity is set to 30 story points for a 2-week sprint, the capacity details will show the percentage of how full the sprint is in terms of the estimated story points.
- When using time-based estimates, capacity is measured against the duration of a week. If weekly capacity is set to 200 hours for a 2-week sprint, the capacity details will show the percentage of how full the sprint is in terms of the estimated hours.
- Even if a story spans multiple sprints, its estimate will consume capacity from the sprint that's assigned to it. For instance, TIS-123 is scheduled for 20 days, and it spans sprints 1 and 2 because each sprint runs for 10 days. TIS-123 is assigned to sprint 1, so its estimate of 30 story points will be allocated to sprint 1.
For Kanban teams:
Capacity is measured against the duration of a week. If weekly capacity is set to 200 hours, then the capacity details will show the percentage of how full the iteration is in terms of the estimated hours.