Workload

Purpose

Workload metrics diagnoses if there are people in a team with over- or under-allocated capacity for a selected iteration - based on estimated tasks (in Hours) assigned to team members. This helps monitor a quality of sprint plannings and adjust effort distribution to team members. This dashboard is most valuable for the active sprint/release or at sprint planning.

Limitations

To have the value from this widget, there're several important prerequisites:

  1. Team is working via either Sprints or Releases, i.e. on a pure kanban-like flow this widget show anything valid

  2. Tasks must be assigned to people (otherwise will be indicated as "Unassigned")

  3. Tasks must be estimated in hours (otherwise buckets of assigned work will weigh just zero)

  4. Each task/story is assigned to 1 person (break down into sub-tasks wherever necessary), i.e. no multi-assignments of a big Story to a chain of people

For ACTIVE or FUTURE sprints/releases

For active or future sprints/releases the charts on this screen mostly deal with the Remaining Estimates of efforts known at the moment (more precisely - at last data feed) compared to the Remaining Capacity of the team. This answers, in overall, "how much work is currently assigned to team members" i.e. if team members are likely to successfully accomplish all assigned activities. Manager can re-adjust assignments appropriately e.g. review priorities and pull some less-important work out of a sprint so that team could focus on the most important scope.

Every day you look at the progress over active sprint/version, its information will change because team burn their remaining estimates as well as their capacity is melting day after day.

Workload Summary

For a selected iteration (a sprint or version) this summary shows:

  • Aggregated team workload. Calculated as remaining estimate of tasks assigned to team members divided to a remaining capacity of all team members for the same iteration. The aim is to have it in a green zone.

  • Remaining work assigned.

  • Remaining capacity of a team till the end of a current sprint/version and the initial capacity for the same iteration.

  • Ratio of un-estimated items in iteration backlog. The closer this absolute value to 0, the better. The best practice is to start a sprint with ALL items properly estimated.

  • Ratio of un-assigned items in iteration backlog. This bar shows a percentage of items that weren't assigned to team members. 

  • Duration of an iteration in total working days and remaining working days.

Workload Details

Shows a per-person workload for selected iteration. It allows tracking how much work is assigned to every team member, how much time is remaining available and how much time was already logged. The following attributes are available for every person in a team:

  • Workload: Allocated hours (upper bar for each person) - calculated as a total estimate of tasks (a sum of "remaining estimates") currently assigned to a team member.

  • Workload: Reported hours (lower bar for each person) - total time already reported by a team member onto tasks of selected iteration. Click a person name to view details. 

  • Assigned un-estimated items - a warning icon. Click it to view details. 

  • Workload % - shows a percentage of a team member workload. Calculated via Allocated hours divided to a remaining capacity of a team member (capacity can be managed on Capacity screen). The aim is to have it in a green zone. Click a person name to view assigned items. Workload % is sortable via click on a column header in the grid.

For COMPLETED sprints/versions

For completed sprints or releases (versions) this screen answers "how much work was assigned to the team in the past". You may retrospectively review the workloads with your team to understand if those were adequate, although no chance to change anything because sprint/release is already completed.

Efforts here are taken as Remaining Estimate at the moment each item appeared in a sprint for the first time - i.e. no matter if it was planned from the beginning or was added in the middle, both cases are covered. Team capacity for completed iterations is static and limited with a start/end date of a sprint/release.

Workload Summary

For a selected iteration (a sprint or version) this summary shows:

  • Aggregated team workload. Calculated as total estimate of tasks assigned to team members divided to a total capacity of all team members for the same iteration. The aim is to have it in a green zone.

  • Total work assigned i.e. a sum of "remaining estimates" at the moment each task jumped into a sprint/release.

  • Total capacity of a team for a selected sprint/version.

  • Ratio of un-estimated items in iteration backlog. The closer this absolute value to 0, the better. The best practice is to start a sprint with ALL items properly estimated.

  • Ratio of un-assigned items in iteration backlog. This bar shows a percentage of items that weren't assigned to team members. 

  • Duration of an iteration in total working days.

Workload Details

Shows a per-person workload for selected iteration. It allows tracking how much work was assigned to every team member, how much time was available and how much time was already logged. The following attributes are available for every person in a team:

  • Workload: Allocated hours (upper bar for each person) - calculated as a total estimate of tasks that were assigned to a team member in that iteration.

  • Workload: Reported hours (lower bar for each person) - total time already reported by a team member onto tasks of selected iteration. Click a person name to view details. 

  • Assigned un-estimated items - a warning icon. Click it to view details. 

  • Workload % - shows a percentage of a team member workload. Calculated via Allocated hours divided to a total capacity of a team member (capacity is managed on Capacity screen). The aim is to have it in a green zone. Click a person name to view assigned items. Workload % is sortable via click on a column header in the grid.

Personal details and assignments

How people are picked here:

  1. Taking every Assignee from the issues within a selected sprint/version (by a physical assignment to appropriate sprint or version)

  2. Adding every name who logged their work to issues within a selected sprint/version

  3. Adding every name who has modified any field of Status, Sprint, Fix Version, Assignee, Original Estimate, Remaining Estimate, Story Points, Flag (on or off), Labels, Priority, Issue Type, Description within a time frame of selected sprint/version

As soon as you click a name of any team member - personal details get opened in a separate window which will drill down to specific tasks, with ability to filter and search within those details.