DEV Community: alexey

Tracking Individual Velocity and Metrics

alexey — Sun, 14 Sep 2025 19:11:05 +0000

Jira's built-in Velocity Report does not support tracking individual or personal velocity, as doing so contradicts Agile and Scrum principles. While this approach is not recommended in traditional Agile environments, many teams still find value in tracking individual metrics for performance analysis or personal development.

With Multi-team Metrics & Retrospective, you can leverage the custom JQL metrics feature to track individual velocity or any other personalized metric.

How to Set Up an Individual Metric

To create an individual velocity metric:

Enter edit mode in your dashboard.
Add a new custom metric and give it a clear name (e.g., “James Completed Scope”).
In the Underlying Metric (the pre-built metric to which your JQL code will be applied) dropdown, choose:

Completed Scope to calculate individual velocity, or
Any other predefined metric if you're targeting a different measurement, or
None if you'd like to define the metric entirely from scratch.

4.In the JQL Code section, add the following filter:

assignee = %NAME_OF_THE_PERSON_TO_TRACK%

5.Optionally:

Select a custom color for visual clarity.
Choose the columns you’d like to display in the detailed view.

Visualizing the Results
Once configured, you’ll get a view like this, displaying progress and dynamics - how a person/engineer/developer is performing over time. It shows changes compared to the previous period and how much work was accomplished out of the Final or Initial Scope:

You can also dive into a specific period for more focused analysis:

If you need to compare individual metrics across team members, teams, or timeframes (sprints, months, quarters, half-years, or years), the app supports side-by-side comparisons in a single unified view:

Bonus: Individual Retrospectives
The app also allows you to run individual retrospectives directly in place, helping you reflect on performance trends and growth areas over time.

For more on how to conduct these retrospectives, read the article Quantify your retrospectives to unleash the full power.

Why your JIRA Velocity and Sprint Reports most likely calculated incorrectly

alexey — Mon, 12 May 2025 22:58:01 +0000

Have you ever stopped to analyze what work-items are actually counted toward the velocity? If not, you likely don’t get a reliable the Velocity and Sprint Reports.

Here are four common pitfalls that can seriously distort your velocity — and how my app Multi-team Metrics & Retrospective can help fix them mostly automatically:

Do you remove work-items from a sprint only when they were deprioritized and never when they were incomplete before the sprint was completed (to move them to the next sprint or backlog)? If the answer is no — note that the Sprint Report doesn’t consider removed work-items as uncompleted ones.
Do you always put all the work-items in a sprint? The Sprint Report’s ‘Issues completed outside of this sprint’ metric only takes into account work-items that were completed outside of a sprint AND after that add to a sprint. There is quite a high probability that if you analyze at least a quarter, you will see several work-items resolved outside of a sprint and never added to it.
How do you manage duplicates? It depends on your case, but in general if you keep them outside of a sprint they can be lost, if you add them to the sprint you need to make sure that they eventually don’t have estimates. In enterprises there can be dozes of duplicates.
Don’t you have estimates for overlapping activities — for example, when you estimate a story/feature for a sprint (which generally should take into account all the work needed to deliver the task), and after that estimate a bug created by your or an external team?

And as a bonus, if 3 and 4 items resonate with you, and you conduct retrospectives on issues added to a sprint after it was started, it becomes tedious to distinguish Added Scope worth analyzing from the Added Scope that was included for obvious reasons — expected testing or duplicates. Just as a reminder this type of metric is not a separate metric per se in the Sprint Report. Added Issues are just marked with a ‘*’, you need manually and visually scan work-item by work-item.

All the outlined issues can be resolved by educating people, overseeing the processes, and manually maintaining the order.

Or you can use the app I developed which will let you decrease the pain at least twice. The options the app provides:

Automatically include Removed Scope in Final Scope and Uncompleted Scope (if it wasn’t completed) automatically.
Automatically include Scope Completed Outside in Final Scope and Completed Scope automatically
Automatically exclude from all metrics issues linked as duplicate to issues in the same sprint
Automatically exclude from Added Scope (which is a separate metric) and Re-estimated Scope issues linked as ‘testing discovered’ (the link type is automatically created by the app) to issues in the same sprint.

Part of the Configuration Screen:

The Dashboard View:

Quantify your JIRA retrospectives to unlock the full team’s potential

alexey — Mon, 21 Apr 2025 02:58:58 +0000

How does your team conduct retrospectives? Do you rely on Confluence or Miro using techniques like “Start, Stop, Continue” or the 4Ls? Have you ever tried to measure whether your team has genuinely improved over time — whether over a quarter or a year?

You might already be tracking DORA metrics, test pass rates, code coverage, or static analysis results — but how do you actually identify, categorize, and prioritize the underlying issues that are holding those metrics back?

Chances are, most teams haven’t set up a clear system to track whether those root problems have been truly resolved — or even measured progress toward addressing them. In some rare cases, such a system might exist, but for most, it’s still uncharted territory, since extracting meaningful data from scattered visualization tools and sometimes chaoticly organized wiki pages is often a time-consuming process.

Think about how many times have you labeled a problem as “TBD”, which eventually ended up in a backlog of other “TBDs” that you later had difficulty prioritizing? What happens when some of these require executive approval, such as securing additional budget to allocate more computing power for faster compilation or to run intensive test suites? In many cases, teams abandon their efforts to provide robust data, making it difficult to justify budget requests or prioritize lingering issues effectively.

I’ve faced these challenges countless times. That’s why I developed Multi-team Metrics & Retrospective — a solution that transforms retrospectives into quantifiable, data-driven processes. One of the most crucial aspects of effective retrospectives is analyzing failed commitments, particularly incomplete scope. Through experience, I’ve found that the best way to drive improvement is by evaluating failed work items against well-defined metrics over a chosen time period — be it a sprint, month, quarter, half-year, year, or product release. To make this process seamless, a structured framework is essential.

A Framework for Data-Driven Retrospectives

To effectively track and improve team performance, we need:

1. Visualizing Key Metrics with Bar Charts
Bar charts offer an intuitive way to track key retrospective metrics such as Uncompleted Scope, Unestimated Scope, etc. These charts can be configured to reflect different timeframes — sprints, months, quarters, half-years, or years — allowing teams to monitor progress over time. Displaying multiple teams within the same view provides a comprehensive perspective, especially when teams share a backlog or operate within the same domain. Since teams may define success differently, having the flexibility to create and track custom metrics adds further value.

2. In-Place Retrospective Analysis
Rather than switching between tools, users should be able to click on a bar in the visualization, view the list of failed work items, and categorize them using a predefined but customizable dropdown. A dedicated space for documenting preventative measures ensures that retrospectives go beyond discussion and translate into actionable steps — all within a single interface.

3. Reports on Key Performance Blockers
Teams should be able to generate reports that identify the top reasons for underperformance over any selected time period. Furthermore, these reports should enable historical comparisons — for example, tracking performance in 2024 vs. 2023 for a single team or multiple teams in the same domain (e.g., “Team1, Team2” in Domain ABC). This helps teams identify trends and measure improvement over time.

4. Drill-Down Capabilities for Granular Insights
A high-level report is useful, but real insights come from the ability to drill down into details. If the reporting period is a year, teams should be able to explore how work items were distributed across half-years, quarters, months, or sprints — all from the same interface. This flexibility allows teams to pinpoint when and where performance bottlenecks emerged.

…

Why This Framework Works

With these components in place, the common retrospective challenges vanish:

Retrospective outcomes become quantifiable, accessible in two formats: bar charts with key metrics and pie charts summarizing failure reasons across different time periods.
If you need to analyze work items that failed for the same reason, you simply click on the reason within the report.
To identify the most pressing impediments, you can generate a priority-ordered report listing the most common failure reasons, along with the number of associated failed work items.
Conversations about budget allocation or team performance with top management become data-driven and easier to justify.

The Impact of a Data-Driven Approach

Implementing this framework requires effort, but the rewards are immense. In my experience, the last team that adopted this structured approach achieved:

2x increase in delivery throughput and velocity
3x increase in flow efficiency
4x increase in planning accuracy and commitment fulfillment

Previously, I experimented with third-party apps and manual workarounds to implement parts of this framework in Jira. Eventually, I decided to develop a dedicated solution — Multi-team Metrics & Retrospective — to bring everything into one streamlined tool.