Skip to content
Snippets Groups Projects
Open Capacity planning and resource management
  • Capacity planning and resource management

  • Capacity planning and resource management

    Open Epic created by Gabe Weaver

    Important: Splitting a single person's time across teams is an anti-pattern and should be a last resort

    Problem

    We can use velocity and volatility (&435) to forecast estimated completion ranges for a given backlog that has been estimated via weight. Fluctuations in team capacity have a significant, negative impact on the reliability of using historical velocity to plan upcoming iterations.

    Scenario:

    1. A team has been tasked with building an MVP and needs to communicate deadlines with executives and coordinate on GTM with other stable counterparts like marketing and sales.
    2. The team breaks down the MVP into epics/issues and roughly weights the scope. They determine there is 300 weight worth of scope.
    3. The executive asks when the project will be done. The project lead says it is too early to tell, but he will provide a likely date ranges at the end of the next four weeks.
    4. The team gets to work....

    During the next four weeks, the team's output looked like this (source):

    Time Period Weight Completed Weight Remaining Velocity Volatility
    1 10 294 10
    2 40 254 28 76%
    3 25 229 27 56%
    4 18 211 24.75 51%

    With this data, the project lead can map out the remainder of the project scope:

    Time Period Expected Weight Rem. Best Case Weight Rem. Worst Case Weight Rem.
    5 186 174 199
    6 162 136 187
    7 137 99 175
    8 112 61 163
    9 87 0 151
    10 63 139
    11 38 127
    12 13 115
    13 0 103
    14 91
    15 79
    16 67
    17 55
    18 43
    19 31
    20 19
    21 7
    22 0

    Completion forecast uncorrected for capacity:

    • Expected completion date: Week 13
    • Best scenario completion date: Week 9
    • Worst case scenario complete date: Week 22

    Problem: This does not take into account fluctuations that naturally occur when a team member takes PTO, there is a holiday, and so on.

    Opportunity: How can we make this forecasting process more accurate?

    MVC Proposal: Individual works on a single team

    • An individual can be assigned to an Iteration Cadence.
    • A team has an iteration cadence (&5077) to manage their recurring iterations.
    • For any given current or upcoming iteration, a team member's availability can be adjusted between 0 and 100%.
    • Aggregate availability across team members for a given iteration to calculate the overall team capacity.
    • Normalize the weight of completed issues to account for this in order to prevent wild swings in velocity/volatility due to capacity changes.

    Scenario:

    Let's say that a team knows that a few team members will be out for future time periods...

    • time_periodX = Monday - Friday
    • The team consists of 5 individuals. Each individual has a capacity of 7 hours per workday.
    • You can then model the team capacity according to the following table...

    At 100% capacity, each cell is a % based on % = x / 7:

    Person 1 Person 2 Person 3 Person 4 Person 5
    Day 1 7/7 = 100% 100% 100% 100% 100%
    Day 2 100% 100% 100% 100% 100%
    Day 3 100% 100% 100% 100% 100%
    Day 4 100% 100% 100% 100% 100%
    Day 5 100% 100% 100% 100% 100%

    So in the future, the team knows about the following loss of capacity:

    • During time_period5, Person 2 is OOO.
    • During time_period7, the entire team has a holiday.
    • During time_period8, Person 5 is getting a root canal and will miss half a day.

    Team strength can then be calculated as follows:

    Person 1 Person 2 Person 3 Person 4 Person 5 Total Capacity Units Projected Available Units Team Strength
    time_period5 100% 0% 100% 100% 100% 175 140 80%
    time_period6 100% 100% 100% 100% 100% 175 175 100%
    time_period7 80% 80% 80% 80% 80% 175 140 80%
    time_period8 100% 100% 100% 100% 90% 175 171.5 98%

    Right now, velocity and volatility would react strongly to these sorts of changes in capacity, so we need to work towards normalizing velocity to take this into account. We need to start tracking normalized_weight alongside the actual weight completed in each Iteration.

    It works like this:

    • If my team is < 99% capacity, we want to normalize the velocity for that Iteration so it is calculated as if the team was at 100%.
    • If the velocity for time_period5 is 23.25 and our team capacity is 80%, we can determine the normalized_weight according to the formula normalized_weight = 1 / .8 (capacity) = 1.25. So for every unit the team completes at 80% capacity gets recorded with a normalized_weight value of 1.25.
    • The team won't complete more units, but we can offset the capacity loss so that it doesn't impact the team's normal velocity/volatility.
    • The inverse is true if the team is over capacity for a certain time_period. If the team is at 125% capacity, the normalized_weight value would be 1 / 1.25 = .8, which would lead to the velocity/volatility to not be exaggerated in the opposite direction.

    When we take into account the normalized_weights to help prevent wild swings in velocity/volatility as well as accepting the fact that a team with less capacity will obviously be able to complete the same amount of actual units, we can provide a more accurate forecast:

    Time Period Expected Weight Rem. Best Case Weight Rem. Worst Case Weight Rem. Strength
    5 192 182 203 80%
    6 169 146 192 100%
    7 151 117 184 80%
    8 128 82 173 98%
    9 105 46 163 100%
    10 81 10 152 100%
    11 58 0 142 100%
    12 35 131 100%
    13 12 121 100%
    14 0 110 100%
    15 100 100%
    16 89 100%
    17 79 100%
    18 68 100%
    19 58 100%
    20 47 100%
    21 37 100%
    22 26 100%
    23 16 100%
    24 5 100%
    25 0 100%

    Our more predictable model that takes into account team capacity now shows:

    • Expected completion date: Week 14
    • Best scenario completion date: Week 11
    • Worst case scenario complete date: Week 25

    Not simple: Individual shared with multiple teams

    • There are scenarios where an individual may work on more than one team.
    • That individual allocates x% of their time to one or more iteration cadences. The % across the cadences must sum to 100%.
    • Similar to the above but add "global availability" on the user level.
    • Intelligently set per iteration availability based on date overlap across all iteration cadences to which the individual belongs

    Linked items ... 0

  • Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading