Investment categories
Everything you need to know about setting up your Investment Balance and configuring your organization's categories.
How it works
The Investment Balance shows activity on pull requests and issues grouped by the configured investment categories and includes both completed issues and merged pull requests. Over a longer period of time, we've seen that these activities are a reliable proxy for understanding development time.
Multiple investment breakdowns
You can configure more than one way to break down your work into distinct sets of categories.
The primary breakdown is meant for the most important categorization you want to track company-wide, is visible everywhere in Swarmia, and has a bunch of tools to help you increase data quality.
You can create additional breakdowns that are available exclusively on the Investment Balance view.
Activities shown in the report are based on the team members
If your team members have contributed towards issues belonging to other teams, those issues will also show up. Think of this as not a bug, but a feature: the team is investing its time somewhere, and the report shows you where that investment goes, even if it's not for the things you might've expected.
How work is grouped by category
We start by looking at all contributions by all team members of the selected team, then determine the investment category based on the rules you've set up.
Then work is grouped by investment category. (These categories are mutually exclusive and collectively exhaustive within any single breakdown.)
If multiple tasks belong to a bigger project, it's possible to have different investment categories assigned to each task and the project as a whole. In this case, we'll show each task in its respective category of work.
Each issue or pull request can link only to one category. All work not linked to a category will show up as uncategorized for the primary breakdown, or the similar last catch-all category for additional breakdowns.
In other words, categories are mutually exclusive and collectively exhaustive.
Determining the category
The logic for determining an issue’s category works in the following order:
Setting the category for the issue manually takes precedence over everything else. (Manual override)
If the issue matches one or more category filters, it will be linked to the top most matching category. You can re-order the categories in settings.
If the issue is a child of another issue (parent) that either matches with category filters or is manually categorized, it will inherit from the parent issue. The inheritance works several steps down the issue hierarchy.
If there are no category matches, the issue will show up as uncategorized.
For instance, if we have the following issue hierarchy with issues uncategorized, with the exception of one bug that matches the filters for KTLO:
If the top epic would then be categorized as New Things, all the uncategorized children of the epic would also get categorized as New Things. Bug 1 (and any children it might have) would not be automatically categorized as New Things (as it matches step 2 in the logic).
Automated filters can be configured in a way that makes an issue match multiple categories. In this case, we'll assign it the first category that matches. You can re-order categories in settings to influence that.
If there are no investment category matches of any kind, the issue is considered uncategorized.
The logic for determining a pull request's category is similar:
Linking PRs to categories takes precedence over everything else.
If the PR is linked to an issue that's categorized, the PR is assigned the same category.
If the PR matches one or more investment category filters, it will be linked to the first matching category.
If there are no category matches, it will show up as uncategorized.
Configuring your investment categories
You can configure a set of Investment Categories for you organization in the Organizational Settings. There are different ways to think of investment categories. Many of our customers use primarily the Balance Framework by Dropbox for balancing engineering investments. Additional approaches to grouping work include:
Company initiatives
Product focus areas
R&D Capitalization / R&D expenditure
Releases, or a company level roadmap (e.g. "Q3")
Setting up your filters
Using our automated filters, you can assign work to categories based on certain criteria.
We support a variety of filter options for both Pull Request data and Issue data.
Your filter might be as simple as this:
But reality is often a bit messier. In a large organization, each team might have their own little quirks in how they track their work. For instance, let's say most teams use Epics and Stories for Roadmap work... but some also use specific labels for that purpose, and one team stubbornly wants to use their custom Jira issue type.
No problem:
Categorizing work items one by one
In addition to being able to categorize work items with automated filters, it is possible to directly choose the category of an issue or pull request for the primary investment breakdown. To do that, select an individual work item in one of the many views in Swarmia, then click on Categorize in the popup if the issue is uncategorized or the issue type dropdown if it is currently categorized, then select the desired category.
Improving categorization rate
A high categorization rate (more than 80% of work categorized) is essential to have good visibility into where engineering time goes. The investment balance view highlights the uncategorized work and makes it easy to assign the right categories for the remaining items.
Best practices
Sort at the highest level available Use labels or custom fields at the Epic level to quickly categorize work. Child issues and work will inherit the parent's category.
Create catch rules Sometimes it's easier to create rules to remove certain data points. E.g. capture reactive work by using a rule like 'Jira type is Bugs, Defect'
Start simple If you don't have the practice of doing this today, start by simplifying the categorization and rules to build the practice over time. If you have an existing way of thinking about this, start there.
Improve over time Swarmia has tools to help build the practice over time. These include working agreements to help teams link pull requests to issues and tools to help group Uncategorized work.
No categorization applied yet — all work items are uncategorized.
Items labeled Feature are categorized as “New things.” This label is applied at the Epic level, and the categorization is inherited by all child Stories, Tasks, and PRs.
Items with the Jira type Bug are categorized as “KTLO.” This overrides the inherited “New things” categorization from the parent and reclassifies them under KTLO instead.
Items owned by the Platform team are categorized as “Productivity.” This categorization is based on team ownership, not labels or issue types.
Last updated
Was this helpful?