How are Personal Capacity Limits Calculated?
Personal capacity limits on People Capacity and Capacity Calculation views are calculated using the number of remaining working days of the Sprint (Iteration) or Release, the number of Weekly Hours available for a Person, and the Percent Participating value taken from user allocations.
People Capacity is calculated in a different manner for work scopes that belong to Projects (i.e. Iterations or Sprints, and Releases) and Teams (i.e. Team Iterations). Both cases are described below.
People capacity is calculated only for single Iteration / Release / TeamIteration so far. The capacity is calculated separately per each Release or Iteration. Your Releases should not overlap by start and end dates, because people capacity is not distributed in Releases that are run in parallel.
Personal Capacity Limit in Iterations (Sprints) and Releases
Four values are multiplied together for every Person:
Capacity = R * H * W * P
R = Remaining Working Days
This value is amount of working days remaining till the end of work scope period (Release / Sprint /Team Iteration). For non-started periods the capacity values are maximal. When the work scope period is current (in progress), then capacity decreases day by day. For past work scope periods personal Capacity is always 0.
Only standard working days (Mon - Fri) are considered. The current day is included in the calculation. Capacity decreases once a day (as soon as current date changes).
Let's say we have a Sprint with a duration equal to two weeks. It starts on Sunday, Feb 19 and ends on Saturday, Mar 4. A week has 7 calendar days and 5 of them are working days, so the full length of the sprint is 14 calendar days and 10 working days.
Before the Sprint started, its remaining duration was equal to the number of working days within it.
R = 10
Let's imagine the Sprint already started and today is Thursday of the first week of the Sprint, Feb 23. On the roadmap current day is shown as thin vertical green line while the Sprint itself is displayed as a rectangle.
In this case, the number of remaining working days for the Sprint is equal to 7 = 2 (current week) + 5 (next week).
R = 7
H = Hours per day
In Targetprocess, this value is permanent. It equals to 8 hours per working day and cannot be changed.
H = 8
W = Weekly Hours / 40
This value is personal. For each user it is specified in Personal Account Settings. Default value for Weekly Hours is 40.
We divide the value by 40 to get a multiplier for resulting formula.
W = (40 / 40) = 1
P = Percent Participating / 100
Percent Participating (availability in %) is taken from user allocations on a Project during the Iteration time frame when such data is specified. 100% or 0% values are used otherwise.
Project members do not have Allocations to the Project
If no allocation are specified for the user, then his/her allocation becomes equal to 100% by default.
This user has no allocation specified.
P = (100 / 100) = 1
User does not have allocation to the project, while other project members have them
If at least one of the users is allocated to a Project you should allocate others as well. Otherwise capacity of users with missing allocation will be calculated with 0% availability.
User is allocated to other projects
If a person is assigned to a project with no allocation set and at least one allocation is specified for some other project, then Targetprocess assumes that user's availability for the current project is 0%.
Allocations are Specified for the User in the Project
If a person is assigned to a Project and at least one allocation is specified in the User Allocations list, then Targetprocess tries to find an allocation that overlaps Sprint dates and takes Percent Participating from there.
This user is allocated to Project1 with 50% availability in 2017 Q1.
P = (50 / 100) = 0.5
The User has Allocations on the Project, there are Working Days not Covered by Them
If some days of the Sprint are not covered with an existing User Allocation to the Project, then the Percent Participating for this user during these days becomes equal to 0%. Amount of working hours for these days is reduced from total capacity limit.
P = (0 / 100) = 0
Let's say we have a two week Sprint and it has not started yet. 10 working days remain in the Sprint. The Team works 8 hours per day.
The Developer has 40 weekly hours available. He is assigned to a Project but his allocation to the Project is not specified.
Capacity = R * H * W * P = 10 * 8 * (40 / 40) * (100 / 100) = 80 hours
Now let us consider a two week Sprint where today is Thursday of the first week. 7 working days including today remain in the Sprint. The Team works 8 hours per day.
Our part-time Developer has 30 weekly hours available and he is assigned to the parent Project with 50% user allocation during the Sprint's duration.
Capacity = R * H * W * P = 7 * 8 * (30 / 40) * (50 / 100) = 21 hours
Personal Capacity Limit in Team Iterations
For Team Iterations, capacity is calculated in the same manner. It is displayed in a very limited case, only when all of the following is true:
- The Team Iteration contains work from only one Project
- Selected effort units for the work in the Project are hours
- The Person is a member of both: the Team that the Team Iteration belongs to, and the given Project
People Capacity cannot be calculated for Team Iterations containing work from several Projects for the moment.
How to set Partial Personal Allocation for a Team Iteration?
As Team Iterations do not belong to any parent Project, it is not possible to specify if a Person is partially allocated for any Team and Team Iteration so far. Please vote for this Idea in our public Backlog if you require this unreleased feature.
Still have a question?
We're here to help! Just contact our friendly support team