# Customize Work Categories Each organization works differently. Our custom configuration allows you to accurately understand *what work has been completed* at your organization, based on issue tracking data from integrations like Jira and Linear. We hope this will help keep teams on track and prioritize work. ## Work “completed” definition {% tabs %} {% tab title="For a Jira integration" %} Work completed = work that has been moved to the `Done` status, or to a custom status in the `Done` status category. Use the toggle on the chart to show the sum of issues or total story points. For example: if you have custom Jira statuses like `Testing`, `In Staging`, `Ready for Release`, and `Released`, and the last 2 statuses are both in the `Done` category, then we count number of issues moved either to `Ready for Release` or `Released`. Note: We exclude subtasks from the analyses. {% endtab %} {% tab title="For a Linear integration" %} Work completed = work that has been moved to `Done`. Use the toggle on the chart to show the sum of issues or total story points. We include both issues *and* sub-issues in our sums. {% endtab %} {% endtabs %} ## How to customize “work” completed {% tabs %} {% tab title="For a Jira integration" %} Work can be defined by using [Issue Type](https://community.atlassian.com/t5/Jira-articles/Understanding-issue-types-in-jira/ba-p/1497237), [Epic,](https://support.atlassian.com/jira-software-cloud/docs/what-is-an-epic/) and/or [Label](https://community.atlassian.com/t5/Jira-articles/Using-labels-in-Jira/ba-p/1782833) (you can not select Subtask or issue types of [custom hierarchy levels](https://support.atlassian.com/jira-software-cloud/docs/configure-custom-hierarchy-levels-in-advanced-roadmaps/)). We will only show epics that are currently in an “open”-type status. * If you define a category using an epic that later gets closed, the chart will still show the issues in that closed epic for that category, until you decide to remove this epic from the category definition. * If you remove the closed epic from your configuration, it will disappear from the epics dropdown and you will no longer be able to use it. Our default for `Types of Work` is to categorize issues by `Issue Type`. The Jira defaults for this are `Story`, `Bug`, or `Task`, but you may have your own custom issue types. Our default for `Feature vs Maintenance` is to categorize issues by `Issue Type`, where issues called bug, tech debt, or chore are displayed in various shades of purple, to indicate that it’s all `Maintenance work`. All other issues are grouped into the green `Feature work.` Note that an older release of this chart defaulted to categorizing issues based on whether it *contained* a string called `bug`, `tech debt`, or `chore`. Now, the config default will look for an exact match (of course, configurable!). {% endtab %} {% tab title="For Linear integration" %} Work can be defined by using [Project](https://linear.app/docs/projects) and/or [Label.](https://linear.app/docs/labels) Our default for `Types of Work` is to categorize by `Project`. Our default for `Feature vs Maintenance` is to categorize by `Project`, where projects called bug, tech debt, or chore are displayed in various shades of purple, to indicate that it’s all `Maintenance work`. All other projects are grouped into the green `Feature work`. You can define categories of work based on combinations of `OR` and `AND` conditions. For example, you can define a custom work category, `Customer Support`, that is defined as where an Epic is `Support`, and the Label is one of `Customer Apple`, `Customer Grape`, `Customer Peach`. Configure these categories based on how your teams think about where your time goes. This will help to see at-a-glance where your team’s split of time is what you would expect. Note that we run our Linear pipeline hourly, so changes you make to issues in Linear will come through in an hour or less. {% endtab %} {% endtabs %} ## How "work" is defined in custom configurations * Each chart’s configurations are organization-wide. * For now, we do allow categories to overlap: * If you define a custom work category called `Support` which includes work where Label is `Customer`, and another custom work category `Customer` which also includes work where Label is `Customer`, then work completed with a Label that is `Customer` will be counted in both categories. * This helps some companies that prefer to have an accurate relative comparison of work across categories. * In the Feature vs Maintenance chart only, we will flag this discrepancy because it means some issues are being double counted, and it inflates the total issues done for that week or month (to over 100%). * For now, we handle work that falls outside custom categorization differently across the two charts: * In the `Types of Work` chart, anything that is not captured by custom categories will go into the `Unassigned` bucket (which cannot be removed) * In the `Feature vs Maintenance` chart, you have 2 options. Work that falls outside configured rules can either be: * Counted as `Feature work`, by selecting the “Everything else” option when editing the Feature category (see image below; this is the default - since a lot of teams are using this chart to get a quick high level view of the two buckets, it’s easier to think of all work that’s not Maintenance as part of the Feature) * Not counted at all, by selecting the “Only specific issues” option when editing the Feature category (see image below; this means some work will be completely excluded from the chart if it isn’t captured by the defined conditions)

Edit feature category

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.multitudes.com/configuration-and-setup/customize-work-categories.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.