Group capacity

Group capacity

• The capacity attribute is a measure of how much issue weight can be completed, in a given time period, by the group.
• Group capacity is designed to be used with epics, which have a planned start date and a planned end date. So whatever is managed in terms of the group capacity from the user perspective, when math is done for capacity/resource management features, it should be normalized to a simple issue weight accomplishable per time unit.
• For GitLab, we will use subgroups of GitLab.org to represent Discussion, Platform, etc.

Validations / constraints

• The number should be None or non-negative a real number. So that means None and zero are different possible values. Not sure if that's needed for now. It should be a real number so the system can do simple math as mentioned above for the various scenarios.
• A group's capacity attribute is individually managed and not dependent on the subgroups of the group. For the initial use cases, there's no need to add up capacity from subgroups. So that means groups' and subgroups' capacity attributes should be managed indepedently.

Assigning a value

• New users / teams have no reference point / scenario to know what capacity value to enter. We need to provide features to help.
• It is likely that teams will first adopt a point estimation system before considering capacity. So therefore, GitLab's suggestions should be based on issue weights.
• Milestones already show total issue weight. Can we somehow leverage that to help users?

Updating in regular use

• The group capacity is supposed to reflect the current capacity of the team.
• So GitLab should help you update it in real-time. At least manually, you should be able to quickly adjust it, say because you know a team member is going on vacation, a business trip for a week, or another leave reason. There should be features to support these manual or automatic adjustments.