Capacity Planning

The sprint capacity fields, and the team capacity page that reports committed hours against available ones

Capacity in Elixion, the platform for Engineering Intelligence™, is two separate things: a number you set on a sprint, and a reading of how much open work each member is carrying. People and agents appear in the same reading, because both are assigned issues.

A sprint's capacity

A sprint carries two capacity fields, both on its Overview tab, both editable while it is Draft or Planned:

  • Capacity (story points)
  • Capacity (hours)

They save as you leave the field, or on Enter. Once the sprint is Active the panel locks and shows them as text.

The story-points figure is the one the product compares against:

| Where | What it does | |-------|--------------| | Sprint planner | The Capacity meter, reading planned against capacity with a percentage. Amber above 90 percent, red above 100 | | Sprint Overview | The Capacity value in the metric strip, and an over-capacity line beneath it when the plan exceeds it | | Sprints page | The same line under the active sprint's Burn block, and a short badge on a planning card | | Adding an issue | A running sprint pushed past its capacity raises an over-capacity message | | Completing a sprint | A destination sprint that would be pushed past its capacity raises a warning in the dialog |

Every sprint carries a capacity figure, so every one of those signals has something to compare against: a sprint created without a capacity is given the project's default rather than left blank. The signals read whatever the sprint currently says, which is why the over-capacity line prints both numbers instead of only the verdict. If the capacity it quotes is not the one your team would have chosen, edit it on the Overview tab while the sprint is Draft or Planned.

The over-capacity line names both figures, and it gets stronger wording once the plan reaches one and a half times capacity: a sprint planned at 281 points against 85 reads as far over capacity, at 3.3 times.

It is about a plan you can still change, so it appears while a sprint is in planning or running and stops once the sprint has been completed or cancelled. A closed sprint's story is told on its Reporting and Report tabs instead.

When you create a sprint, the capacity field is pre-filled from the project's measured average velocity where one exists, and otherwise from the project's default sprint capacity scaled to the duration you chose.

Team capacity in hours, on the planner

The planner also prints an hours figure for the featured sprint, with its arithmetic in view: 4 members × 10 working days × 8h/day = 320h. The member count is the project's people, the working days come from the project's settings, and the hours per day is a stated assumption. The formula is shown precisely because that last number is an assumption rather than a measurement.

The Capacity page

Insights > Capacity, at /capacity, or press g then w. It is headed Team capacity, with the line: workload and utilization across the team. It reports on the project selected in the project rail.

The period it measures

One control scopes the page: a sprint dropdown. Its first option depends on what is running:

  • Active sprint (name) when the project has a sprint running. Utilisation is measured over that sprint.
  • All open work when nothing is running. Every open issue is measured against one week of capacity, and the page labels the period so the figure is not read as a sprint.

Picking a named sprint measures against that sprint instead.

What the numbers mean

Committed hours count open work only. Issues that are Done or Deferred are excluded, so finished work cannot inflate anyone's load. Each open issue contributes its original estimate in hours, or, where it has none, its story points multiplied by four.

Available hours are the member's weekly capacity across the period: weekly capacity multiplied by the length in weeks of the sprint bounding the view. A member's weekly capacity is 40 hours unless a different figure is stored for them.

Utilisation is committed hours divided by available hours.

The four bands

| Band | Utilisation | |------|-------------| | Under | Below 60 percent | | Optimal | 60 to 85 percent | | High | 85 to 100 percent | | Over | Above 100 percent |

What the page shows

A summary strip across the top:

  • Members
  • Capacity, in hours, with the available hours underneath
  • Avg utilization, as a percentage, with the period it covers
  • Committed, in hours

Under it, a breakdown counting how many members fall in each band, then the team list, sorted by utilisation with the heaviest first. Each row carries the member's avatar, name, a User or Agent tag, their role, a utilisation bar coloured by band with its percentage, their committed hours against available hours, and how many of their tasks are complete.

Agents appear in the list alongside people, with the same figures, when the page is scoped to a project.

With no project selected the page asks you to pick one. With no member carrying work it says so, rather than drawing an empty chart.

What the calculation includes

The figures are built from issue assignments and estimates. Absences, holidays, allocation percentages, on-call rotations and per-skill capacity are not part of the calculation, and the page has no date-range picker: the sprint dropdown is the scope control. To change what a sprint is measured against, change the sprint's own capacity fields or the issues in it.

Next: Kanban Board, where the same work appears as cards.