## Capacity planning and resource management

### Capacity

### Epic weight

- An epic's weight is determined by the sum of its issues and the issues of all descendent subepics.
- An epic's open weight is determined by the sum of all its open issues and open issues of all descendent subepics.

### Epic assignees

- An epic can be assigned any number of groups.
- An epic can be assigned by any group in the GitLab instance, not just the group in which the epic belongs to.
- When you assign a group to an epic:
- If the group is already assigned to a descendent epic, the group gets unassigned from the descendent epic first, and then gets assigned to the epic at hand.
- If the group is already assigned to an ancestor epic, the group gets unassigned from the ancestor epic first, and then gets assigned to the epic at hand.

### Capacity planning and resource management

- Give a group, see all the epics at that group.
- See all the assignees for all those epics.
- Epics at this level may have descendent epics, which have assignees. But we don't account for those. We only account for assignees at this level.
- Look at the set of assignees assigned to epics in this group. For the purpose of capacity planning and resource management, assume these assignees are not assigned to any other work.

### Earlier end date based work assignment algorithm

- For a given group, with epics that have positive open weight:
- View when the epic will be estimated to have work complete (and thus see if it's delayed, compared to its end date).
- For epics that have end date already before today, it will already be delayed, so see how much longer it will be delayed.

- The algorithm prefers work with earlier end dates to be done first, if it exists, as first priority, breaking ties arbitrarily.
- Next is work with earlier start dates to be done first, if it exists, as a second priority, breaking ties arbitrarily.
- Next is work with no start dates and no end dates. These are ordered arbitrarily.
- When the algorithm begins, all assignees (groups), start off at today's date. As they are assigned work, they move forward in time, accounting for the work to be done.
- Every time you load the page, the algorithm runs and presents the results in a visualization. There is no "state". It is just based on these items that are configured by the user:
- Weight of issues, and how they are scoped in epics, thus remaining weight of epics.
- Start and end dates of epics.
- Capacity of groups.
- Assignment of groups to epics.

### Example of algorithm running

#### Algorithm Loop Iteration 1

- At this point in the algorithm: All A, B, C, D are available starting today (Feb 15)
- Looking forward in time from today, find the next epic that is already started, has remaining weight, and has earliest end date.
- That epic is W.
- W has assignees A and B, with a combined capacity of 3 / day. W has remaining weight of 180. So A and B will work on W for 60 days and finish it.
- W's work will be complete on today (Feb 15) + 60 days = Apr 16. So W will be delayed. A and B will be freed up to do work on Apr 16.

#### Algorithm Loop Iteration 2

- At this point in the algorithm:
- A, B are available starting Apr 16
- C, D are available starting todday (Feb 15)

- Looking forward in time from today, the next epic to consider is Z.
- Z has assignees A and D. From today to Apr 16, only D is working on Z since A is busy with W. Afterward, both A and D are working on D until it finishes.
- From today to Apr 16 is 60 days so during that time, D contributes to 60. From Apr 16 onward, both A and D contribute together for a combined 2 / day. So they finish on Apr 26. During that final section, they contribute 20 together. So the full 80 remaining weight is done.

#### Algorithm Loop Iteration 3

- At this point in the algorithm:
- A is available starting Apr 26
- B is available starting Apr 16
- C is available starting today (Feb 15)
- D is available starting Apr 26

- Looking forward in time from today, the next epic to consider is Y.
- Only D is assigned to Y. D is available to start work starting Apr 26. Since D's capacity is 1 / day, D finishes the required 4 weight in 4 days. So Y's work ends on Apr 30, ahead of schedule.

#### Algorithm Loop Iteration 4

- At this point in the algorithm:
- A is available starting Apr 26
- B is available starting Apr 16
- C is available starting today (Feb 15)
- D is available starting Apr 30

- Looking forward in time from today, there are no more epics that have already started from today.
- Move the reference time forward until you hit an epic that has started with open weight. That reference time is Mar 1.
- Find the next epic to consider from the reference time of Mar 1. That epic is X.
- X has assignees B and C. From Mar 1 to Apr 16, only C is available. So during this first stretch of 46 days, 92 weight is completed. And then in the final 4 days from Apr 16 to Apr 20, both B and C are working, with a combined capacity of 3 / day. So during those final 4 days, they complete 12 weight. So that means in Apr 20, the required 104 weight is complete for X. X is delayed.

#### Assignment results

- 3 of the epics are delayed. The other one ends ahead of schedule.
- Groups A, B, D work 100% of the time. Group C is not doing work from Feb 15 to Mar 1.
- Visualization would be on roadmaps page, and it would be similar to above mockup.
- This is a real-time view of how the future will evolve based on current assignments. It is a
*planning*tool since from this visualization, you should be able to drag-extend or drag-shorten epics. You should be able to drag-drop groups to assign/unassign to different epics.

### How GitLab would use this

- Epics scoped at the GitLab.org group. Issues remain in the CE and EE projects of GitLab.org.
- Epics represent projects with a defined start and end date. Typically they would span multiple milestones.
- Issues would have assigned weights and thus, reflect the epic weights.
- Typically, we would have a GitLab crew working on each epic. We would manually assign a capacity estimate to that crew. The crew would be a GitLab group (it would be a subgroup in the GitLab.org group).
- The crew would be composed of frontend and backend engineers, at least one designer, and at least one product manager. Since the bottleneck usually is in engineering capacity, the capacity assigned to the crew would be driven by realistic capacity of the frontend and backend engineers, with the assumption that designers and product managers would not need to be accounted for in terms of capacity. (And thus, the weight of epics should not reflect designers and product mangers work either.)
- A crew would work on multiple epics. But an epic would only have one crew working on it.
- If a crew needs to work on multiple overlapping-in-time epics, this algorithm would then tell us how realisitic that is and give us an estimate of it is feasible given the scheduled timelines. This algorithm would
*not*support a crew working on multiple epics*at the same time*. But that would be an anti-pattern anyways. So that is okay for this initial iteration of the feature. - Product managers and engineering managers and the UX manager would work together to manage and use this tool for planning and tracking over time. They would plan epics together to see what is realistic and be able to more reliably plan for the future.
- Other stakeholders would
*consume*this to know when major features (epics) are being worked on and when they would be completed. - If there is urgent work that comes up that disrupts existing plans, we would make those assignments and we would see how they would impact existing epics and progress. In the typical case, we would delay current epics by extending their end date further out in the future.