Use investment categories to get insights on how your team's time is spent between different types of work.
There's a lot going on all the time in most organizations. But are you spending your time on things that matter? Swarmia's investment categories help you find out.
Investment categories help teams categorize work completed in GitHub, Jira and other tools to find patterns in how they spend time and boost focus on top priorities.
In Swarmia, you can use default investment categories or come up with categories of your own.
Configure investment categories in organization settings.
Setting up investment categories
There are different ways to think of investment categories. Some of our customers use this framework by Dropbox for balancing engineering investments. Other 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")
Using our automated filters, you can assign work to categories based on certain criteria.
We support the following issue filters:
- Projects (e.g. DEV - Development project in Jira)
- Issue type
- Jira issue type (e.g. "Initiative" in Jira)
- Swarmia issue type (e.g. "Epic"). Using Swarmia issue types allows comparing teams that use Jira issue types differently.
- Issue keys (e.g. DEV-1251)
- Team ownership
- You can define issues owned by each team in Swarmia's Jira settings
- Issue tracker labels
- Custom fields
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.
Categorize issues one by one
In addition to being able to categorize issues with automated filters, it is possible to directly choose the category of an issue. To do that, select the issue (e.g. in Work Log), 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.
Using the same dropdown, an issue that has been directly categorized can also be uncategorized.
Categorizing pull requests
Not all work is visible on the issue tracker, however. It's common for developers to just create pull requests for things where it feels like it would take too much time to create an issue for the small task at hand, and link your pull request to that issue. In reality, such unplanned work may add up to a significant portion of engineering effort in your organization.
Categorize PRs one by one
Swarmia helps you take this kind of work into account, by allowing developers to assign unlinked pull requests directly to applicable investment categories. For each investment category, there's a checkbox allowing you to select if you'd like to allow categorizing pull requests to it:
This allows you to categorize unlinked pull requests to these categories from the Pull Requests view with just a few clicks. For teams that are using the pull request linking working agreement, they can also do it right from Slack:
Categorize PRs automatically
Pull requests can also be categorized automatically with rules. To do that, click the "Include pull requests" button in category rules and select an applicable rule to include any matching pull requests.
When this is done, the pull requests are included in that category if they haven't been linked to any specific issue already, or if they haven't been manually assigned to any category as described above.
How we show work by category
Each issue or pull request can link to only one category. All work not linked to a category will show up as uncategorized.
In other words, categories are mutually exclusive and collectively exhaustive.
Determining the category
When an issue is categorized, all its uncategorized child issues are assigned the same category by default. Furthermore, these children's child issues also inherit the category by default, and so forth.
For instance, if we have the following issue hierarchy with issues uncategorized, with the exception of one bug:
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.
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 pull request category is the same:
- 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.