Team Capacity management in Kendis is essential to make sure your PI plan is realistic and that your teams don't burn out. It provides a transparent, centralized view of the ART's available bandwidth, helping you avoid overcommitment and ensure predictable delivery.

Access, Visualize, and Measure Team Capacity

Access: You can open the capacity workspace by clicking the “More” button and then selecting “Team Capacity”.

Measurement Flexibility: You can define and view capacity using different units, toggled by a filter, By Story Points or By Number of Stories.

Team Filtering: Use the selected team filter to narrow the view down to specific teams for focused analysis.

Board Visualization: On the Program Board itself, each Sprint column displays two crucial letters for a quick audit. L (load) is the committed work, and C (Capacity) is the next budgeted capacity available to the team.

Understanding the Values of the Capacity Grid

The capacity grid provides the core data. In this board, the default per user capacity is set to 8 (points or stories). Each cell in the grid displays three core data points.

Total Team Capacity: The total Stories/Story Points the team is committed to deliver in the Sprint.

Story Points Assigned: The number of Stories/Story Points currently committed to this team for this Sprint. This value turns red if overloaded.

Story Points Achieved: The total number of Stories/Story Points the team has completed in this Sprint (for tracking).

Editing Team Capacity and Adding Users

The Team Capacity window functions as the workspace to define capacity, audit current load, and manage user commitments across sprints.

Editing Team Capacity: To add or adjust capacity for a specific team, click "Enable Editing" located next to the team's name.

Adding Team Capacity and New Users: New users are added via the "New user" section at the bottom. The system supports adding existing users, or adding non-Kendis users by defining their Name, Role, and Location.

You can also add users directly from your agile tool, Jira or Azure DevOps.

Click the search option (e.g., "Search From AzureDevOps") to pull existing users from the tool into the capacity grid. Jira users will have the “Search From Jira” option.

Individual Capacity Input: Once editing is enabled, capacity values can be entered into the Sprint cells for individual users. The Team Capacity row automatically aggregates and sums these values to establish the team’s total capacity and total load assigned.

Note: You can create a license-free placeholder user and assign capacity to manage the aggregate Team-Level capacity instead of tracking it individually.

Auditing Committed Load: Simply click the value to investigate the origin of the Story Points Assigned. A detailed pop-up displays all constituent work items (stories/features), including their Key, Status, Estimate, and Percentage Done, providing full transparency into the assigned load.

Customization and Reporting

You can easily customize the display of user data. Use the Settings dropdown to toggle the display of columns like Show Role and Show Location. Simply toggle off these options if the user data is not relevant to your current planning session.

For external reporting and auditing, the entire Program Level Capacity grid can be exported in XLS format directly from the Capacity screen.

Team Capacity Visualization on Program Board

To visualize capacity per individual user, use the "No Groups" dropdown at the top of the Program Board. Under the "Select" menu, choose Responsible (Features) or Responsible (Stories) for Azure DevOps. For Jira, you can select Assignee (Features) or Assignee (Stories).

When the board is set to group by assignee, the committed capacity values will be visible for each user within their dedicated swimlane. This allows for a precise, focused audit of individual workload against their assigned capacity, ensuring resources are not over-allocated.

User Roles and Permissions

Team capacity editing access is allocated by specific user permissions. Admin can set these permissions or customize views for better auditing.

Enabling Editing Access

Follow these steps in the administration menu to manage the permissions that allow a specific user to edit capacity.

Go to Settings in the left navigation panel, and then select Roles from the submenu.
Click Add Role or edit an existing custom role (e.g., Scrum Master).
To enable capacity editing on the Program Board, ensure the user role is granted the "Sprint Capacity" permission, which is found under the Board Settings section in the custom role configuration.

To grant higher-level management access, ensure the user role is granted the "Manage Capacity" permission, which is located under Planning Agenda & Related Views.

Team Capacity Analytics

To get a more detailed view, you can switch to the Analytics tab. This tab uses highcharts to visualize team capacity, load, and work done so far.

Team Capacity Summary Table

This table provides a high-level overview of the entire ART's capacity, load, and remaining buffer:

Capacity (C): The total budgeted capacity for the team (aligns with the C on the board).

Load (L): The total committed work in Story Points for the team.

Capacity - Load (C - L): The remaining buffer or overload. A negative number (e.g., -28 for Cherokee) indicates the team is severely overloaded.

Data Breakdown: You can view the aggregate data broken down by the number of Features, Stories, and Story Points across the entire Program Increment.

Sprint-by-Sprint Capacity Bar Chart

This chart allows for a visual audit of a single team's health across the PI:

Capacity (Blue Bar): The total capacity planned for that specific Sprint.

Current Load (Purple Bar): The current committed work assigned to the team.

Previous Load (Light Blue Bar): The amount of work carried over or planned before the current view.

Done Story Points (Green Bar): The Story Points completed during the Sprint, allowing for progress tracking.

Overload Visualization: Comparing the Capacity Bar (Blue) against the Current Load Bar (Purple) instantly highlights any Sprint where the team has been over-committed (e.g., in Q3-Iteration-2, Load is 15, Capacity is 12).