Velocity per user is not a valid Agile metric. In Scrum, velocity measures how much work a team completes per sprint — not how much each individual contributes. Tracking it at the individual level distorts estimation behaviour, damages collaboration, and undermines the purpose of velocity as a planning tool. Jira does not provide individual velocity natively, and Atlassian explicitly advises against using it as a performance measurement.
When teams start exploring Jira velocity charts and custom dashboards, the question of individual velocity comes up often — usually from managers who want more visibility into who is contributing what. The instinct is understandable. The outcome is usually counterproductive.
This guide explains why velocity per user creates problems in Scrum, when individual velocity data might be used carefully, what to measure instead, and how to access per-user data in Jira if you have a legitimate use case for it.
Related: Scrum Velocity Chart: How It Works in Jira and How to Use It for Sprint Planning — the full guide to team velocity in Jira.
Velocity per user — sometimes called individual velocity or velocity by assignee — refers to tracking story points or issues completed by each individual team member per sprint, rather than measuring the team’s total output.
Jira’s native Velocity Chart shows team-level totals only. It cannot be filtered by individual user or assignee. To see velocity broken down per person, teams need a reporting add-on such as Report Hub, which provides per-user velocity views inside Jira Cloud.
The data exists — every issue has an assignee and a story point value. The question is not whether you can measure individual velocity, but whether you should, and what happens when you do.
In Scrum, velocity is explicitly a team metric. The Scrum Guide defines the Scrum Team as a unit — not a collection of individuals with separate performance targets. Velocity reflects how much the team delivers together per sprint, and is used to inform future sprint commitments.
Tracking velocity at the individual level contradicts these principles in several specific ways:
Teams that implement individual velocity tracking typically see a predictable sequence of events. In the first sprint or two, the data looks informative — you can see who completed more points. By sprint three or four, estimates start creeping up. By sprint six, the team’s average velocity has “improved” significantly — but delivery speed and quality have not. The metric has been gamed without anyone intending to game it.
This is not a hypothetical. It follows directly from basic incentive design: measure something, and people optimise for the measure rather than the underlying goal. In Scrum, the underlying goal is team delivery predictability. Individual velocity measurement reliably undermines it.
There are limited scenarios where looking at per-user velocity data can be legitimate — provided it is used transparently and with clear intent:
| Legitimate use | What to look for | What to avoid |
|---|---|---|
| Workload balancing | Is one team member consistently carrying significantly more work than others? | Using it to pressure lower-output team members |
| Capacity planning | When a team member goes on leave, how much capacity is actually lost? | Treating velocity as a fixed individual output target |
| Coaching | Is a team member consistently over-committing and carrying work forward? Is their estimation pattern different from the team? | Comparing individuals against each other or ranking them |
| Non-Scrum contexts | In Kanban or hybrid workflows, throughput per person can be tracked as a flow metric | Applying Scrum velocity logic to Kanban, where story points don’t apply |
If you have a legitimate use case — capacity planning, coaching, or workload balancing — here’s how to get the data.
Jira’s native Velocity Chart shows team totals only. There is no built-in filter or setting to break it down by assignee.
Report Hub provides a per-user velocity breakdown directly inside Jira Cloud. You can see story points completed per sprint broken down by assignee, filter by date range and project, and compare patterns across sprints — without any data leaving the Atlassian environment.
The view is designed for capacity planning and coaching purposes, not performance ranking. Before using it, share it openly with the team and be explicit about the intent.
If the underlying goal is understanding team performance and identifying improvement opportunities, these metrics provide better signal with fewer negative side effects:
For how to read and use these metrics in Jira, see: Jira Scrum Reports: Burndown Chart, Velocity Chart, Sprint Report and Agile Reports Explained
To use velocity as it was intended — as a team planning tool — keep it at the team level:
If you need deeper insights — estimation accuracy, scope change patterns, delivery trends across teams — Report Hub provides these views at the team level, with the option to drill into individual data for specific coaching conversations when needed.
Velocity per user in Jira refers to tracking story points or issues completed by each individual team member per sprint. Jira does not provide this natively — the native Velocity Chart shows team totals only. Individual velocity data requires a reporting add-on and should be used only for workload balancing or coaching, not performance evaluation.
No. In Scrum, velocity is a team-level metric used for sprint planning and capacity forecasting. Atlassian explicitly advises against using it to compare individuals. Individual velocity can be referenced carefully in limited contexts — workload balancing, coaching, capacity planning — but only with full team transparency and never as a performance ranking tool.
It creates perverse incentives: team members inflate story point estimates to look more productive, choose easier work over higher-priority items, and stop collaborating as freely. The result is that velocity numbers improve on paper while actual delivery predictability gets worse. The metric destroys itself when used this way.
No. Jira’s native Velocity Chart shows team-level totals only and cannot be filtered by user or assignee. To see velocity per person in Jira, you need a reporting add-on such as Report Hub, which provides per-user velocity breakdown directly inside Jira Cloud.
Better alternatives include team velocity per sprint, cycle time, lead time, team throughput, sprint goal achievement rate, and burndown patterns. These metrics identify improvement opportunities and bottlenecks at the system level without creating individual performance pressure that distorts behaviour.
Individual velocity data has limited legitimate uses: identifying workload imbalances during capacity planning, coaching team members who are consistently over- or under-committing, and in non-Scrum contexts where throughput per person is tracked transparently. In all cases, the data should be shared with the full team and never used for performance ranking or comparison.
Velocity per user is not a valid Agile metric and typically causes measurable harm when applied in Scrum environments — to estimation accuracy, to collaboration, and to the usefulness of velocity itself as a planning tool.
Teams that want better visibility into delivery performance have more effective options: cycle time, lead time, throughput, sprint goal achievement, and burndown patterns all provide actionable insights without the side effects of individual velocity tracking.
If you do need to look at per-user data for a specific coaching or capacity planning conversation, use it transparently, share it with the full team, and be explicit that it is not a performance metric.
For the full guide to how velocity works as a team metric in Jira, see: Scrum Velocity Chart: How It Works in Jira and How to Use It for Sprint Planning.
For all Scrum reports available in Jira and how to use them, see: Jira Scrum Reports: Burndown Chart, Velocity Chart, Sprint Report and Agile Reports Explained.
Ready to Elevate Your Jira Setup?
Partner with Grandia Solutions to unlock expert configuration, reporting, and support services — tailored to your workflows. Whether you need custom dashboards, workflow automation, or long-term consulting, our team is here to make Jira work for you.