Skip to main content

​
How capacity is calculated

Before troubleshooting, it helps to know the two capacity modes:
  • capacityLoad — tracks effort at the column (Plan) level using remainingEstimate, initialEstimate, or a custom capacityField. Capacity bars appear per Plan column.
  • multiCapacityLoad — tracks effort per swimlane cell, so each resource row shows its own capacity bar. Uses a multiCapacity map keyed by capacity type name.
Resolved work items are handled specially: effortDone is set to the full effort value, and effortTodo is set to 0.

​
Symptom: capacity bar shows zero or is missing

Likely causes: capacityLoad is not enabled, the effort field is empty on work items, or the field name does not match what Planningboard expects. Steps:
  1. Open the widget parameters for your Planningboard page.
  2. Confirm that capacityLoad is set to true.
  3. Check that work items in the board have values in remainingEstimate or initialEstimate (whichever your configuration uses). Items with no estimate contribute zero effort.
  4. If you are using a custom effort field, verify the capacityField parameter exactly matches the field ID as defined in Polarion — field IDs are case-sensitive and any mismatch silently produces zero.
  5. Save the widget parameters and refresh the board using the refresh button.
Capacity configuration parameters are whitespace-sensitive. A trailing space in a field ID or parameter value will cause the capacity bar to show zero with no error message. Copy field IDs directly from the Polarion field configuration rather than typing them by hand.
You should now see the capacity bars populated with effort totals from the work items in each column or swimlane cell.

​
Symptom: per-swimlane capacity not showing (multiCapacityLoad)

Steps:
  1. Confirm multiCapacityLoad is enabled in the widget parameters.
  2. Verify that each resource (swimlane) has capacity data available. multiCapacityLoad uses a multiCapacity map keyed by capacity type name — if the capacity type name does not match what the swimlane expects, that swimlane’s bar will be empty.
  3. Check the assignment mode. multiCapacityLoad is most effective with the Users (Assignee) (ASSIGNEE) or Enumeration Field (ENUM) assignment modes, where resource IDs are stable and well-defined.
  4. If you use the Teams Service (useTeamsService), verify the Teams Service is configured and returning team member data — Teams Service data overrides plan capacity values.
Use capacityLoad when you want a single capacity bar per Plan column. Use multiCapacityLoad when different resources have different capacities and you need per-row visibility. Note that multiCapacityLoad takes effect only when capacityLoad is also set to true — both must be enabled together.

​
Symptom: effort values look wrong or inconsistent

Work item effort calculation flow: initialEstimate and remainingEstimate combine into effort (total), which splits into effortDone and effortTodo differently for resolved items versus active items
Steps:
  1. Check whether the affected work items are in a resolved state. Resolved items always contribute their full effort to effortDone and zero to effortTodo — this is by design, not a bug.
  2. If effort values appear rounded unexpectedly, note that Planningboard applies rounding to effort calculations. This is expected behavior.
  3. Confirm the hoursPerDay conversion is set correctly if you are mixing time-based estimates with day-based capacity. A mismatch (for example, estimates in hours but capacity in days with the wrong conversion factor) produces misleading percentages.
Planningboard does not split effort across multiple assignees. If a work item has multiple assignees, its full effort is counted once — not divided per resource. This is a known limitation compared to Nextedy GANTT. Plan your capacity expectations accordingly.

​
Symptom: capacity shows correctly for some swimlanes but not others

Likely cause: The Parent Item assignment mode (PARENT) does not support plan normalization (planCellsMode). If you are using parent-item swimlanes, capacity normalization is unavailable for those swimlane rows. Steps:
  1. Check the assignment mode. If it is set to Parent Item (PARENT), capacity normalization is not supported — this is a product limitation, not a misconfiguration.
  2. For Users (Assignee) (ASSIGNEE) or Enumeration Field (ENUM) assignment modes, verify that all swimlane rows have a matching resource entry in the capacity configuration.
  3. If some swimlanes are new (recently added enum values or new users), the capacity map may not yet include them. Update the widget parameters to add capacity values for the new swimlane identifiers.

​
Symptom: capacity changes when switching plans mode

The plans mode affects which Plans are loaded and how effort is aggregated: If capacity looks wrong after changing the plans mode, re-verify that the capacity configuration is appropriate for the new mode. SAFe modes use plan templates to discover plans automatically — if the template filter excludes a plan, its work items and effort are not counted.

​
Symptom: board becomes unresponsive or hangs when loading capacity data

If the board hangs indefinitely when capacity data is loading, the cause may be a network or firewall issue rather than a capacity misconfiguration. Corporate firewalls and proxies can block the requests that Planningboard makes to load plan and resource data. Open the browser console (F12) and check the Network tab for failed or stalled requests. See Network and Firewall Requirements for details on what to check.

​
Known limitation: multi-enum swimlanes and capacity

When work items appear in multiple swimlanes (for example, when using multi-valued enumeration fields for swimlane assignment), capacity calculation behavior across those swimlanes is not yet fully defined. Multi-enum swimlanes were planned for release by end of February 2026 — check the current product version for availability.
Once multi-enum swimlane support ships, verify how effort is counted when a single work item appears in more than one swimlane row. Until confirmed, treat per-swimlane effort totals as approximate in multi-enum configurations.

​
Known issue: cross-project plan loading and page unresponsiveness

If the board becomes unresponsive when selecting a project for a plan template in a cross-project planning scenario, this is caused by a known Polarion issue with cross-project plan loading. Workaround: Add the following property at the global Polarion administration level (not at the project level):
After adding the property, restart Polarion and reload the board.
This property must be set in global Polarion administration, not in a project’s context.properties. Setting it at the project level has no effect on the cross-project plan loading behavior.

​
Verification

After applying any of the fixes above:
  1. Refresh the board using the refresh button.
  2. Confirm that capacity bars appear in the expected swimlane cells or Plan columns.
  3. Spot-check a work item with a known estimate — verify its contribution to the capacity bar matches the expected value.
  4. If using the Teams Service, confirm that user capacity values come from the Teams Service data and not from the plan’s default capacity value (Teams Service values take precedence).
You should now see accurate capacity bars reflecting the effort of work items in each Plan column or swimlane cell, with resolved items counted as fully done.

​
See also

Support TicketsSource Code
  • PlanningBoardDataService.java
  • PlanningBoardWidget.java
  • planningboard.js
  • PlanningBoardWidgetDependenciesProcessor.java
  • PlanningBoardWidgetRenderer.java
Last modified on July 10, 2026