# Notion for JIRA Tutorial

To get the most from your JIRA data in Notion, we recommend getting started with simple framework that will give you an overview of how your team is doing: Speed, Accuracy, Quality, and Joy.

The following tutorial will walk your through the basics of each class of metrics. Think of this as a launch pad for your team to grow from.

## Speed

One of the more popular metrics for tracking speed is Average Velocity. This will give you a rough estimate of how quickly your team moves through the story points in your backlog. Here is the formula to put in your Notion recipe:

**[A]** is the total number of story points in a given period of time, and **[B]** is the total number of Sprints in that period.

You can learn how to track velocity in Notion using JQLs here.

Once you know your velocity, you can now use that number to calculate the health of your backlog by dividing your average velocity into your total backlog. This will give you the total number of sprints worth of backlog you have currently. Here is the formula for Notion:

The formula for Backlog Burn Rate in Notion is similar to velocity, simply **A รท B**

**[A]** is the total number of points in your backlog and** [B]** is the average velocity from the last formula.

Other Speed metrics you might consider are:

- Throughput
- Work in Progress
- Open Pull Requests
- Iteration Flow
- Cycle Time

## Quality

Tracking quality is an important part of running a dev team. After all, who cares how fast you build the house if it falls down once it's completed. There are a number of metrics for tracking the quality of work on a dev team.

The number of bugs is a simple one that you can trend over time to get an idea for whether quality is improving or suffering. A useful metric for tracking quality that we use is Defect Removal Efficiency (DRE). The formula looks like this:

Where **[A]** is the total Bugs found in Development and **[B]** is the total bugs found in Production.

This will give you a feel for the efficiency of your Bug removal process, as well as the overall health of your product. While it would be great to have a DRE of 100%, generally speaking we find that 85% is good and 95% is excellent.

Here is a blog article from our School of Little Data teaching you more about the value of DRE.

Other Quality metrics you might consider:

- Code churn
- Bug Burn Rate
- Mean Time to Detect
- Defect Density
- Number of Pages/Alerts

## Accuracy

This often-overlooked class of metrics can be full of valuable insights. After all, you might be moving really quickly, and producing a quality product, but failing to meet internal or external expectations. It's a really common problem to create the *wrong* product, very quickly and well.

There are a lot of metrics to track accuracy, but let's get started with a simple, useful metric for dev teams. We call it Estimated Point Accuracy (EPA). Here's the recipe (there are a few different ways to conceptualize it, I will lay out two):

Where **[A]** is Points Delivered for a Sprint, and **[B]** is Points Estimated for a Sprint.

With this formulation, the ideal is to be as close to zero as possible, meaning you are hitting your estimates on the nose. Positive numbers mean you estimated low, negatives mean you estimated high.

The other way of thinking of it is as a percentage accuracy. For instance:

Where **[A]** is Delivered Points, and **[B]** is Estimated Points.

This is what you would use if you would prefer to see your accuracy to estimate as a percentage. Remember, since this is an Accuracy metric, you want the end result to be as close to 100% (or zero) as possible, because it means your estimating process is accurate.

Other Accuracy metrics to consider:

- Release Window Accuracy
- Customer Value Polls
- Feature Adoption
- Bouncebacks
- Feature Confidence

## Joy

What we call Joy is one of the less precise metrics groups. With that being said, it can be really useful as a temperature check of your team, or as a counter metric for other metrics to make sure that you are getting a full picture.

While there are other some hard numbers you can track as Joy metrics, for now we will recommend Team Polls. Team polls are easy to create and use. Here are is a sample Team Poll to get you started:

You can send this poll to your development team to get an idea of how confident they are that value was delivered this sprint. This can also be used as an accuracy metric as well.

Other Joy metrics to consider:

- Morale (Poll)
- Preparedness (Poll)
- Quality of Work (Poll)
- Road Map Confidence (Poll)
- Attrition
- Time to Fill Positions
- Average Tenure

With these metrics on your Development Team Dashboard, you have a well-rounded look at your overall team(s) health. At this point, you should also have a pretty good understanding of how to create metrics in Notion.

Now that you have your metrics set up, you could add historical data to Notion, if you have any.

Otherwise, I would recommend that you start to engage your team with the metrics that you have created. You could invite additional users from the organization, integrate with Slack, or build a report to share.