Leadership rarely asks how fast a team is. They ask where the effort goes. How much of last quarter went to new features, how much to fixing bugs, and did the tech debt work we agreed to actually happen? Azure DevOps holds the answer in your work items, but it has no built-in view that adds it up. This guide covers how to read that split honestly and how Agile Analytics shows it without a Power BI report.
Why the split matters more than velocity
Two teams can finish the same number of items while one spends most of its time on new features and the other on rework. Velocity hides that difference. The split shows it, and the split is something a leader can act on: rebalance a team, protect time for maintenance, or ask why bugs keep crowding out the roadmap.
- Count finished work, not planned work. Plans describe intent; finished items describe what really happened.
- Look at a window long enough to be stable. A single week is noise; 30 or 90 days shows the shape.
- Show what could not be classified instead of dropping it, so the totals still add up.
The built-in buckets: features, bugs, maintenance and exploration
Out of the box, Investment Allocation sorts every finished work item into one bucket, in a fixed order where the first match wins. A maintenance tag wins first, whatever the item type. Then an exploration tag, once you have added one. Then Bug or Defect items count as Bugs, Tasks count as Maintenance, and requirement types (User Story, Product Backlog Item, Requirement, Feature, Epic) count as Features. Anything else is listed as Unclassified with its work item type named, so nothing quietly disappears.
- Maintenance tags arrive pre-filled (tech-debt, maintenance, refactor, chore and similar), so the view works with no setup.
- The Exploration bucket for spikes and research stays off until an organisation administrator adds the first exploration tag.
- The view also shows the unplanned share: finished work that arrived inside the same window.
- You see it for each team and in an all-teams row for the whole project, over the last 14, 30 or 90 days.
Your own categories: break down by a Work Type field
Many organisations already have their own vocabulary, often a picklist such as Work Type with values like Run, Change and Maintain. Choose that field under Break down by, and the view groups finished work by its values instead of the built-in buckets. You can rename values that read badly and merge values that mean the same thing, for example "Bug" and "Defect", and weight the split by Story Points if you plan in points.
- Pick a field with a small, fixed set of values that people fill in consistently. A half-empty field tells you about data entry, not investment.
- Count items when sizes are similar or teams do not estimate; weight by Story Points when they do.
- If the two views disagree sharply, that is the conversation: many small items in one category, or a few big ones in another.
One breakdown for the whole organisation
When every manager opens the view on a different field, two people end up presenting two different charts as "allocation". An app admin can make the current breakdown the organisation default, including its renamed values. Everyone who has not picked their own field then sees the same split, and anyone who chose a field keeps their own choice.
Reading team rows against the all-teams row
The all-teams row is the combined picture; the team rows show where it comes from. A balanced project row can hide one team carrying most of the bug work. A project row dominated by one category may be one large team or a pattern everywhere, and those lead to very different conversations. Teams that finished nothing in the window are folded into one line, so a long list of idle teams does not bury the ones that matter.
- Treat a team far from the others as a question, not a verdict. It may own a legacy service.
- If a team row looks emptier than expected, check its area path: team rows are filtered by area path.
- Points are a team-relative estimate, so weighted comparisons across teams assume broadly similar sizing.
Try it on your own data
Investment Allocation is one of the views in Agile Analytics, under Measure. It runs in your browser against the Azure DevOps REST API, so there is no Power BI model, no Analytics view and no personal access token to set up, and work item content is not sent to Baytek. It supports Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and every plan includes every feature.
Related: Investment Allocation setup guide · Delivery metrics for executives · Story Points in Azure DevOps · Pricing