> ## Documentation Index
> Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Capacity Tracking
> Capacity tracking in Nextedy PLANNINGBOARD answers a fundamental planning question: **how much work can a team actually take on in a given sprint or iteration?** Rather than treating all swimlanes as equal co
This page explains what capacity tracking is, how Planningboard calculates and visualises it, and the important limitations you need to understand before relying on it for planning decisions.
***
## The mental model: filling buckets
Think of each swimlane as a bucket. A sprint's capacity represents how full that bucket can get. Work items added to the swimlane pour effort into the bucket. The **capacity bar** — the progress indicator visible at the top of each plan column within a swimlane — shows how full the bucket is relative to its total size.
The bar turns into an at-a-glance signal: a nearly full bar means this assignee's sprint is close to committed; an overflowing bar means the team has planned more than the person can realistically deliver.
***
## How capacity is calculated
Planningboard derives capacity from two sources, depending on how the board is configured.
### From the Teams Service (recommended)
When `useTeamsService` is enabled, Planningboard integrates with the Nextedy Teams Service to obtain per-user capacity per sprint. The Teams Service computes available hours based on the user's calendar and their percentage assignment to the project. This means a user on part-time allocation or away during part of a sprint automatically has reduced capacity for that sprint — the capacity bar reflects their actual availability, not a fixed number.
This is the most accurate mode. It requires the Teams Service to be configured and running for the project. See [Teams Service](/planningboard/concepts/teams-service) for setup details.
### From a fixed hours-per-day value
Without the Teams Service, capacity is estimated using the `hoursPerDay` property (default: `8`). Planningboard multiplies this value by the number of working days in the plan to arrive at a total capacity figure for each swimlane-column cell. This is a simplified model: it does not account for holidays, part-time allocation, or any individual variation in availability.
Capacity configuration properties are whitespace-sensitive. Extra spaces around values in your widget parameters can silently cause capacity not to display or calculate incorrectly. If capacity bars are missing or show unexpected values, verify that property values contain no leading or trailing whitespace.
### Effort tracking: what counts as work
Planningboard measures the "water in the bucket" — the effort committed — in one of two ways:
* **Time-based:** Uses `remainingEstimate` and `initialEstimate` fields from Polarion work items. Planningboard sums these across items in a swimlane-column cell to arrive at total effort, then converts to hours using `hoursPerDay`.
* **Custom field:** When `capacityField` is set to a field ID, Planningboard reads effort from that field (for example, a story-points field) instead of time estimates.
Resolved work items are treated as fully done: their effort is counted as `effortDone` with `effortTodo` set to zero.
***
## Capacity modes
Planningboard offers three capacity modes, controlled by widget parameters:
| Parameter | Default | Purpose |
| ------------------- | ------- | --------------------------------------------------------------------------------------------- |
| `capacityLoad` | `false` | Enables column-level capacity bars (one bar per plan column, aggregated across all swimlanes) |
| `multiCapacityLoad` | `false` | Enables per-cell capacity bars (one bar per swimlane–column intersection) |
| `userCapacityLoad` | `false` | Enables per-user capacity bars, driven by the Teams Service |
**Single capacity (`capacityLoad`)** is the simplest mode. One capacity bar appears per plan column, showing total effort committed in that sprint across all swimlanes combined. Use this for a quick column-wide load signal when swimlane-level granularity is not needed.
**Multi-capacity (`multiCapacityLoad`)** is the richer mode. Each swimlane-column cell gets its own capacity bar. This is what enables the "bucket per person per sprint" view described above — you can see at a glance which assignees are over capacity in which sprints. This mode requires each swimlane to carry its own capacity value, typically populated by the Teams Service.
**User capacity (`userCapacityLoad`)** works alongside the Teams Service to show capacity at the individual user level. This mode is most useful when swimlanes represent individual team members (the `ASSIGNEE` assignment mode).
***
## The capacity tooltip
Hovering over a capacity bar on a Plan column reveals a **capacity tooltip** with detailed breakdown information. This tooltip is only available when capacity display has been configured via widget parameters.
The tooltip gives you a precise read of the numbers behind the visual bar — useful when the bar alone is ambiguous (for example, when two plans have similarly-full bars but very different absolute effort values).
***
## Toggling the resource load view
The toolbar's **Toggle Resource Load visualization** button shows or hides the current load of each assignee in the swimlanes. This is a display toggle — it does not change how capacity is calculated, only whether the visualisation is shown on screen.
This button is useful when you want to temporarily declutter the board view while still having capacity data available on demand.
***
## Known limitations
Planningboard's capacity tracking covers the common single-assignee sprint planning case well, but has meaningful gaps compared to Nextedy GANTT's capacity model. Be aware of these before relying on capacity data for critical planning decisions:
### No multi-assignee capacity distribution
Planningboard does not support work items with multiple assignees for capacity purposes. If a work item is assigned to more than one person, the capacity load is not split or distributed across those assignees. This is a confirmed gap versus GANTT's capacity model. For teams where work items routinely carry multiple assignees, capacity figures in Planningboard will undercount actual load.
### No sub-item effort rollup
Planningboard calculates capacity from the effort fields on the work items directly visible on the board. It does not recurse into sub-items to roll up their effort. If your planning practice records effort on child tasks rather than on the parent feature or story, those child-item estimates will not appear in the capacity bar.
Nextedy GANTT's capacity model supports multi-assignee distribution and sub-item effort rollup. If your team relies on either of these patterns, evaluate whether GANTT's capacity view better meets your needs for detailed capacity analysis, while using Planningboard for the board-style planning interaction.
### Swimlane sort order coupling
The sort order of swimlanes affects item sort order on the board. This coupling means that adjusting swimlane ordering for visual reasons can inadvertently reorder work items within those lanes.
***
## How capacity varies sprint by sprint
A key insight of Teams Service–driven capacity is that the same user's capacity bar is not constant across sprints. If Alice takes leave during Sprint 3, her bucket is smaller for that sprint — Planningboard reflects this by showing a lower total capacity for her Sprint 3 column. This makes it immediately visible that Sprint 3 has less room for Alice's work, which should inform how items are distributed during planning.
Without the Teams Service, Planningboard uses the fixed `hoursPerDay` multiplied by sprint duration, which produces the same capacity for every sprint for every user regardless of actual availability.
This difference matters most for teams with variable availability, part-time contributors, or multi-sprint planning horizons.
***
## Relationship to swimlane assignment types
Capacity tracking only produces meaningful per-swimlane numbers when swimlanes represent identifiable resources — typically individual users (the `ASSIGNEE` assignment mode) or teams. When swimlanes are grouped by a custom enumeration field or by parent work item, capacity bars reflect effort aggregated within that grouping, but there is no inherent "available capacity" for an enum value or a parent item in the same way there is for a person.
For capacity-driven sprint planning, the **Users (Assignee)** swimlane assignment type combined with `multiCapacityLoad` and `userCapacityLoad` is the recommended combination. See [Swimlane Assignment Modes](/planningboard/concepts/assignment-modes) for a full explanation of how each assignment type structures the board.
***
## Normalization and capacity together
**Normalization** is a related but distinct concept. Where capacity tracking shows how much work fits into a swimlane relative to a person's availability, normalization adjusts how capacity is compared across swimlanes of different sizes (for example, swimlanes representing teams of different headcount). Read [Normalization](/planningboard/concepts/normalization) for a full explanation.
***
## Practical guidance
For planning teams setting up capacity tracking for the first time:
* Start with `capacityLoad = true` and the fixed `hoursPerDay` to verify that effort data is flowing correctly from work items to the bars.
* Once effort data looks correct, enable `multiCapacityLoad = true` if you need per-assignee visibility.
* Connect the Teams Service and enable `userCapacityLoad = true` to get sprint-variable capacity that reflects real availability.
* Set `capacityField` only if your team records effort in a custom field (such as story points) rather than Polarion's standard time estimate fields.
For step-by-step configuration instructions, see the capacity guides under [Guides](/planningboard/guides/index).
**KB Articles**
* Introduction to Planningboard
* Planningboard interface & basic interactions
* Swimlane Assignment Types
**Support Tickets**
* [#6681](https://support.nextedy.com/helpdesk/tickets/6681)
* [#6777](https://support.nextedy.com/helpdesk/tickets/6777)
* [#6605](https://support.nextedy.com/helpdesk/tickets/6605)
**Source Code**
* `AssignmentMode.java`
* `PlanningBoardDataService.java`
* `planningboard.js`
* `Config.java`
* `PlanningBoardWidget.java`