How are Personal Capacity Limits Calculated?

Personal capacity limits on People Capacity 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 limits are shown only when the Effort of work items is estimated with the Ideal Hours unit. Points are not supported.

Personal Capacity Limit in Iterations (Sprints) and Releases

Four values are multiplied together for every Person:

Capacity = R * H * W * P

Where:

R = Remaining Working Days

This value is derived from the number of  days that the Iteration (Sprint) or Release lasts. Only standard working days (Mon - Fri) are considered. The current day is included in the calculation.

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.

remain-duration-full

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 timeline current day is shown as thin vertical green line while the Sprint itself is displayed as rectangle.

remain-duration

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 Account Settings. Default value for Weekly Hours is 40.Person Weekly Hours

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.

No Allocations are Specified for the User in the Project

If a person is assigned to Project and no allocation is specified, then his/her allocation becomes equal to 100% by default.

user-no-allocations

This user has no allocation specified.

P = (100 / 100) = 1

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.

allocation-project

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

Examples

Example 1

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.

remain-duration-full

The Developer has 40 weekly hours available. He is assigned to a Project but his allocation to the Project is not specified.

allocation-project-blank

Capacity = R * H * W * P = 10 * 8 * (40 / 40) * (100 / 100) = 80 hours

limit-80h

Example 2

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.

remain-duration

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.

user-allocation-2

Capacity = R * H * W * P = 7 * 8 * (30 / 40) * (50 / 100) = 21 hours

limit-21h

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:

  1. The Team Iteration contains work from only one Project
  2. Selected effort units for the work in the Project are hours
  3. 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

Find out more about our APIs, Plugins, Mashups and custom extensions. Join our community of passionate users and even discuss directly with our developers.

Get started for free

How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy