Capacity planning and resource management
Capacity planning and resource management
Important: Splitting a single person's time across teams is an anti-pattern and should be a last resort
- https://www.extremeuncertainty.com/dont-split-people-across-agile-teams/
- https://www.agilesocks.com/splitting-multiple-scrum-teams/
- https://vitalitychicago.com/blog/for-high-performing-teams-stop-assigning-people-multiple-teams/
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:
- 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.
- The team breaks down the MVP into epics/issues and roughly weights the scope. They determine there is
300 weight
worth of scope. - 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.
- 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 thenormalized_weight
according to the formulanormalized_weight = 1 / .8 (capacity) = 1.25
. So for every unit the team completes at 80% capacity gets recorded with anormalized_weight
value of1.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, thenormalized_weight
value would be1 / 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
- Show closed items