Capacity represents the total amount of work of a team or a team member is able to complete during a period of time. I was wondering what is the set formula to calculate this? Is the capacity only based on the team's availability and hours? Let's say I have 1 team member with 40 hours and 1 issue that has a 2 week period. How does Portfolio determine how much time it is allotted for each week?
It's basically Velocity ÷ team members but also takes weekly capacity into play.
Individual capacity in Portfolio for Jira is determined by dividing the team's velocity and if specified in their availability, it will be reduced and the difference redistributed evenly across the other team member's capacity.
For an example on this behavior, team members on a team with 4 members and a velocity of 200 points would have an individual capacity of 50 points (200 points ÷ 4 team members). If one of those team member's availability is reduced by 20% or 10 points, their capacity would then drop to 40 points and the other 3 team members capacity would be increased by 3 points each to maintain the same velocity.
Thanks for the screenshot, and it looks like there is a bit more data behind the scenes coming into play. The capacity itself is going to have quite a few reasons that there is Free capacity left over.
The main thing to consider is that the scheduling algorithm believes there is nothing is able to schedule at that point and I would recommend looking at the Scheduling behavior and where the issues are scheduled, noting the factors:
Portfolio for Jira uses the following factors to create a sensible schedule of your team's work items:
- Estimates, and required skills and capacity
- Team schedules, e.g. working in either sprint iterations, or in a continuous flow of daily tasks
- Work stages, e.g. whether activities can happen either in parallel or in a specific sequence in the plan
- The sequence of work items, based on start and end release dates
- The ranking of work items in the backlog
- Dependencies between work items in the backlog
- Configurable constraints, e.g. how many people can work in parallel on a story
- The skills of each team member
- Availability of teams and people, taking into account holidays
Additionally as covered in that doc take a look at the Scheduling factors on each of the issue to find out why the issue is located where it is in the timeline, I would guess that there is a dependency or earliest start date or a release set on an issues with a fixed start date, and possibly logged work and one of these items is pushing issues further down the timeline and/or removed some capacity on the logged work items.
Next check the estimation for logged work associated to some of the issues, as the issue may be in the appropriate sprint location but have work logged against the issue and therefore the Estimate is burned down but still on the schedule, so as an EXE with a similar setup, the following has a dependencies of FP-1 Blocked by FP-2, & 7 hours logged on FP-1, and an earliest start date on FP-1 pushing the highest ranked issue out to sprint 15 adding in the large gaps on free capacity and the logged work:
So how is your Schedule and Scope laid out on the plan? Primary things to check, where are the issues associated to each other in the schedule? Also what does the estimation and logged work look like on these issues? are there values on Earliest stat date, dependencies, or Releases associated?
Additionally, this is going to start digging into the data a bit so if you have any sensitive data visible on the plan in your follow up I would recommend filing a Support Request ay https://support.atlassian.com for any follow up screenshots so we can take a closer look.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events