Definitions of Allocation Schemes, and examples of how they can be used to calculate Time Allocation for your organization.
Allocation Schemes (also thought of as Allocation Rules) are used to group similar work items into larger categories to get broader view of how the organization is spending its time. Briefly, an Allocation Scheme is a logical rule that defines what issue and PR metadata is analyzed, and how various issues are aggregated. The Uplevel team works with your engineering leadership to define these rules based on the way that your team works.
Hierarchical Rules
Initiatives, Objectives, and other Parent-Child Relationships.
This category of rules looks to the parent-child relationships found in Jira. For example, at your organization a single issue may be linked to an Epic, which is linked to an Initiative, which is linked to an Objective. These allocation rules traverse the hierarchy up to the required level, and splits out any work items that aren't linked all the way up to the top level.
Work on PRs that are linked to issues that map up to one of the hierarchy items will also show up in this category. If a PR is linked to multiple issues that map to multiple Objectives, then the time is allocated equally across the issues/Objectives.
Categorization Rules
Work Category, Work Type, and other rules that leverage Custom Fields.
This category of rules looks for custom fields being populated at a certain level of the hierarchy in Jira/ADO. Often these custom fields are populated by TPMs / Team Leads / Product teams at the Epic level when they are created. Some organizations make a custom field required upon Epic creation for all Company-managed projects. Often, this is to give a sense of the type of work something can be (e.g., New Features vs KTLO vs Legacy Systems Deprecation vs Escaped Defects).
💡Many organizations look at the Issue level first (because a specific work item may not match the overall scope of the work). For example, Epic ABC-123 might be classified as New Value Creation in the Work Type custom field, however, a Bug in the epic ABC-312might be flagged as an Escaped Defect, while other various stories don't have the custom field populated. Uplevel can either:
- (Recommended) Look first to the issue for overrides, and then look to the epic. In SQL, this is done as:
COALESCE(issue_custom_field,epic_custom_field) AS work_category - Aggregate all work in the epic based on the value of the custom field regardless of what the issue level says.
Uplevel has the ability to combine different custom fields (e.g., if a part of an organization uses one custom field, but another part uses a different one), as well as utilize our ML Issue Classification model to fill in the gaps. Reach out to our team for assistance in creating a hybrid rule like this.