How to measure team performance in Jira with agile metrics

Agile & DevOps, Atlassian, Scrum

3 June 2019 • 15 min read

    Every project manager knows that metrics are a problematic subject in teams. On the one hand, we need metrics to make sure that the project is going in the right direction and the team is becoming more efficient with time. On the other, metrics can often be used negatively, putting team performance first or even justifying after-hours work.

    Even if teams aren’t big fans of metrics, team leaders need them to properly understand whether anything is preventing the team from reaching its top productivity. Tracking agile metrics helps to reduce confusion in the project and reveals the reality of the team’s progress throughout the development cycle.

    An agile project requires tracking two types of metrics: business metrics and agile metrics. Business metrics are the ones that focus on whether and how the solution is meeting the market fit. The agile metrics measure the aspects of the development process. Both are equally important.

    Every business project roadmap needs to include key performance indicators (KPIs) that map its goals. Moreover, it’s a good idea to add success measures for every product requirement – for example, the adoption rate by end-users or percentage of code covered by automated tests. These criteria will become the foundation for your agile project metrics.

    Check out these agile metrics that help to understand the team’s process and make releasing software easier with every sprint.


    Let’s start with velocity. Velocity is a metric that measures the average amount of work a Scrum team completes during every sprint. That work is measured either in hours or story points. Product owners can use it to predict how quickly the team can work through the backlog.

    The idea is to track the forecasted and completed work over several iterations — naturally, the more iterations, the more accurate forecasts. For example, if you want to complete 200 story points from the backlog and you know that the development team generally completes the 50 story points per sprint, then you can reasonably assume that the team will need 4 iterations to complete the required work.

    Expert tip: Monitor how your velocity metric evolves over time. Young teams often see an increase in velocity because they’re actively optimizing relationships and refining their workflow.

    Teams also need to look at their velocity to make sure they deliver cost and performance over time and confirm whether improvements to their process affected a change or not. If you notice a decrease in velocity, it might mean that a part of your team’s process has become inefficient. Address this during the next retrospective session.

    Sprint burndown

    Agile development teams organize projects into time-booked sprints. At the beginning of every sprint, the team comes together for planning and deciding how much work they need to complete within the sprint.

    A sprint burndown report tracks the completion of work throughout the sprint. It compares the time and the amount of work left to complete, measured in hours or story points. The objective is to have all the forecasted work done by the end of the sprint.

    If your team manages to meet that forecast, it’s a stellar example of how agile works at its best. But what if your team finishes early, sprint after sprints? It might mean that they aren’t committing to enough work within the sprint.

    On the other hand, if you see that the team fails to meet the forecast sprint after sprints, they might be committing too much work, and you need to revise your planning strategy. If you fail to break the work down into more granular pieces, you will see how your sprint burndown chart drops significantly rather than resulting in a more gradual burndown.

    Epic and release burndown

    Another useful metric is the epic and release burndown chart. It tracks the development progress over a larger body of work an individual sprints. Note that the sprint often includes the work from several different epics. That’s why it’ tracks both the progress of individual sprints and the epics.

    The concept of scope creep is essential here – it means that more requirements were injected into previously defined projects than necessary. For example, if your team is building a new website, scope creep would be adding new features after the initial requirements have already been prepared.

    Tolerating scope creep during the sprint is a bad agile practice, but scope change within epics is something that happens in agile development as the team moves through the project. For example, the product owner may decide to take in more work or remove work based on the findings so far.

    The epic and release burndown chart informs team leaders about the flow of work inside a given version or spic. If you notice chronic scope creep, it’s a sign that the product owner might not fully understand the problem the project is trying to solve.

    Control chart

    The control chart comes in handy if you want to take a closer look at the cycle time of individual issues. That’s the total time it takes for your team to get tasks from ‘in progress’ status to ‘done.’

    Teams that have consistent cycle times across many issues are considered predictable in delivering the work on time. The cycle time is an essential metric for Kanban teams but that doesn’t mean Scrum teams can’t benefit from it is as well.

    Measuring the cycle time helps to improve your team’s processes because you will instantly see the results of changes. The objective here is developing a consistent and short cycle time, depending on what type of work we’re talking about.

    Expert tip: Create a control chart for every story point value to check it for consistency. The idea is developing a consistent cycle time for work items that have similar story point values. If you notice that the cycle time is erratic on both small and large story point values, use the sprint retrospective to examine the process and improve future estimation.

    Cumulative flow diagram

    This diagram comes in handy for Kanban teams because it helps them to make sure that the flow across the team is consistent. The diagram includes the number of issues and time, with colors that indicate various workflow states such as ‘to do,’ ‘in progress,’ and ‘done.’

    This helps to visually identify shortages and bottlenecks, helping you to understand how your team is doing better. The diagram should look smooth from left to right. Any bubbles or gaps in one color indicate bottlenecks – when you see one, you need to focus on smoothing out the color balance in your chart.


    Another critical metric to track is defects. It’s a good idea for agile teams to track how many defects are found during development, following the release to customers, and by users outside of the team.

    Moreover, team leaders should ask how many defects tend to be deferred to future releases. Testing can be a part of that area as well. It helps to gain a better understanding of the quality software that goes into production after every sprint.

    Create performance reports

    So how do you make sure that your team is tracking all of these metrics? By equipping them with a tool that allows doing that. Atlassian’s Jira Software offers a host of features and functionalities that improve product management by formalizing workflows and automating tasks.

    Tracking these metrics in Jira Software really easy and helps team leaders to understand the performance of their team better, pinpoint bottlenecks, and solve problems before they become significant issues.

    Do you need help in installing and configuring Jira Software for optimal team performance? Contact our consultants; we help companies take full advantage of project management software like Jira in tracking the performance of their teams.

    [contact-form-7 404 "Not Found"]