# Feature vs Maintenance Work

{% hint style="warning" %}
Note: this metric is **only shown at a team level**, not an individual level.
{% endhint %}

![Bar chart showing feature vs maintenance work](https://cdn.prod.website-files.com/610c8a14b4df1ae46b1a13a3/6670cedb1f81010b735dcc6e_Feature%20vs%20Maintenance%20Work.jpg)

**What it is:** This shows the relative percentage of either `Feature` or `Maintenance work` completed. For more information, see **How we calculate it** below.

**Why it matters:** Delivery is about managing the balance between shipping new features and maintaining existing systems. If you neglect maintenance, your codebase and systems can [“rot”](https://en.wikipedia.org/wiki/Software_rot), slowing down delivery of new features and site reliability. On the other hand, spending too much time on maintenance can cause the team to miss delivery targets.

This is why visibility over where your team is spending their time is important, to make sure that the balance reflects your priorities.

**How we calculate it:** We may show multiple Feature vs Maintenance charts, depending on whether you have issue tracking integration(s) installed:

* **For our Jira or Linear integration:** this depends on your configuration. [Click here](https://docs.multitudes.com/configuration-and-setup/customize-work-categories) to understand more about how we define what is considered “work” and when it is considered "complete".
* **For our GitHub integration:** this is based on all commits with [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) prefixes.
  * This includes all commits, not just the commits that are merged into production (which may be squashed commits).
  * You can filter for just conventional commits and/or just the commits on each repository's [default branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch) with the toggles above the chart.
  * For the moment, we have set the default mapping using the most common [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) prefixes to our categories as follows:
    * Feature: `feat`, `perf`
      * Investment: `build`, `ci`, `chore`, `docs`, `refactor`, `style`, `test`
      * Bug: `fix`
      * Unassigned: all other commits e.g. if they use a different prefix, or don’t follow the conventional commits format.
  * You can customize the categories. Click the "Edit Categories" link under the legend, and either choose an existing category to "Edit", or "Add category".
    * You may select the prefixes counted towards a particular category using the dropdown of common conventional commit prefixes. Prefixes that are already used in another category will be disabled.
      * You can also type your own custom prefix strings. Press enter after typing each one.
      * There is also a checkbox labeled "Include GitHub revert commits in this category". This is for catching the commits created via the "revert" button on the GitHub UI, which creates a PR (and therefore an eventual commit if the PR is squash merged) in the format Revert "feat: old PR title with conventional prefix".

{% hint style="success" %}
**What good looks like**

Many teams set aside an upfront “tech debt budget” or “maintenance budget” when planning upcoming work. Many will allocate 10-20% for maintenance, but this depends on the team. For example, teams focused on maintaining legacy code might budget 50% of work (whether story points or issues or commits) to maintenance. 

Another approach is to allocate specific days, such as 1 day every week or fortnight. To learn more check out this article on [how to define and spend your tech debt budget](https://hackernoon.com/how-to-define-and-spend-your-tech-debt-budget-8429z32h2) and this one on [reclaiming tech equity](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity). 

Once you have defined a budget, it’s easy to use this chart to track real world “spend”!
{% endhint %}


---

# 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/metrics-and-definitions/process-metrics/value-delivery/feature-vs-maintenance-work.md?ask=<question>
```

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.