Hi @Tejasvita Madan , It’s great to see the team tackling individual capacity planning. This is a high-priority feature for myself and the rest of the engineering leadership team.
Do you have a timeline for when this might move into Beta, or will there be another round of EAP invites? thanks
ALM/Rally provides a very simple and intuitive UI for individual-level capacity planning. Once a team is selected, resources are automatically populated based on the onboarding already done in ALM. A similar capability exists in Jira as well, where navigating to a space shows a Capacity tab and allows adding people directly.
In ALM, capacity can be entered in hours at the individual level. After entering the capacity, ALM automatically pulls the task data for the selected sprint and shows the workload. For example, if Tom’s capacity for Sprint 3 is set to 40 hours and he has tasks totaling 45 hours in that sprint, ALM clearly shows his load as (45/40) × 100, i.e., ~110% utilization for Sprint 3.
In contrast, capacity planning in Jira is unnecessarily complex. We are required to enter hours, days, or percentages for every week and against individual work items. This approach is cumbersome, unintuitive, and adds significant overhead without clear value.
A much simpler solution already exists conceptually in Jira through the Plans tab, where team capacity can be entered at the sprint level and we can see the team loading for a particular sprint. Jira could easily extend this capability to show all work assigned to the team for that sprint and automatically calculate individual and team-level loading. Since teams and team members are already defined in Plans, this would have been a far more straightforward and scalable implementation.
I strongly recommend simplifying Jira’s capacity planning by aligning it with the ALM/Rally model or by extending the existing Plans functionality to support sprint-level capacity planning and workload visibility.
Looking forward to a positive response and an improved experience in this area.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
Excited to see this feature! A few things others have raised that we'd strongly echo:
+1 on Story-level support and having more ways to measure — Epic-only is limiting for teams doing detailed capacity planning, and ideally capacity would be based on story points available, not just the count of work items assigned
Also +1 on making this available in Plans and custom filters for cross-space visibility — many of our people work across multiple spaces run by different PMs and a single consolidated view is essential
We'd love to be included if another EAP round opens up!
Two additional questions from our team as we think through how this would work in practice:
Workload source beyond Assignee
Will workload calculation be limited to the Assignee field, or will there be support for other user fields (e.g. Reviewer, QA Owner, or custom user-picker fields)?
In many workflows, the person doing the work isn’t always the Assignee — it’d be great to configure which field(s) drive capacity and/or some kind of weighting as to what those user fields signal.
Excluding stalled/blocked issues from active workload
Will there be a way to exclude issues in certain statuses (e.g. Blocked, On Hold) from counting toward a person’s workload?
Someone can be “assigned” to 10 epics but if 7 are blocked, their real capacity is very different — the current model could significantly overstate how loaded someone is.
Where do we see the latest updates for the EAP and information on the functions? I was expecting to see it here on the community page but we notice updates in Jira first. It would be helpful so we can communicate it through to our delivery team.
31 comments