
The code/ticket traceability report shows you how consistently software engineers write code in version control systems like GitHub, GitLab, Azure DevOps, or Bitbucket that is traceable to tickets or issues in systems like Jira or GitHub Issues.

The report first looks at how many commits are untraceable because they are made directly to a main/master branch, or to a shared integration branch such as develop, staging or qa.

Next, the report looks for code that is untraceable because it is merged directly (e.g., using the git merge command) to main without using a pull request (called a merge request in GitLab).

Finally, the report shows how often code links to a known ticket. It searches branch names, commit messages, pull request titles, and pull request bodies for ticket links.

Because real life is never 100% perfect, the scores are weighted by how much time developers spend on untraceable code. This helps you focus on improving in areas that will have the biggest impact, with the goal of driving down the percentage of untraceable work.

This report also lets you drill down into teams, people, and specific pull requests to identify the biggest sources of untraceable work.


## Why Is Code/Ticket Traceability Important?

Code/ticket traceability is important because it lets you see where people – your most valuable resource – are spending their time.


### Cost Capitalization

Traceability is crucial for accurately allocating developer salary costs to tasks, projects, and initiatives in your ticketing system.

Cost allocation is a requirement if you’re doing R&D or cost capitalization for accounting (which is now mandatory for U.S. companies due to [Section 174](https://www.kbkg.com/tax-insight/kbkg-tax-insight-irs-releases-guidance-on-section-174-re-expenses)). But, even if you’re not capitalizing development costs on your balance sheet, CEOs, CFOs, and boards often want to see where their engineering salary costs are going for management purposes.

Without automated code/ticket traceability, organizations often resort to manual time tracking. Not only does manual time tracking actually waste developers’ time; it is less accurate because people tend not to log separate entries for small tasks and interruptions, which can have a big impact in aggregate.


### Change Control Compliance

Code/ticket traceability is also a critical component of a secure software development process.

If developers write code that makes it into production without having an associated pull request and ticket, then there is no record of whether it was properly reviewed and prioritized according to the organization’s change control policies.

Failure to follow change control guidelines can result in insecure or improperly vetted code reaching customers, which can compromise the organization’s security.

Furthermore, if you undergo a security audit for standards like SOC 2, untraceable code puts you at risk of having an audit exception if discovered by the auditor. The code/ticket traceability report can also be a great piece of evidence to provide to auditors to demonstrate consistent compliance with change control procedures.


## How Does the Code/Ticket Traceability Report Work?

The code/ticket traceability works by identifying all of the commits made by each author in your organization. It then associates these commits with merges and pull requests. Finally, it looks at commit messages, branch names, pull request titles, and pull request bodies to find ticket IDs that link back to your ticketing system.

The report then calculates how much time is spent on each commit to provide an overall score showing the percentage of traceable coding time, which is aggregated by team, person, and pull request.


## FAQ


### How does the code/ticket traceability report match ticket identifiers?

The code/ticket traceability matches ticket identifiers using a regular expression pattern that looks for valid ticket identifiers. It is case-insensitive and tolerates certain typos.

Additionally, the report verifies that any matches correspond to actual tickets, so, e.g., DEV-99999999 would not count as traceable unless a ticket with that ID actually exists.


### Where does the report look for ticket identifiers?

The report looks for ticket identifier matches in the branch name (also called a “ref”), pull request title, and pull request body. It also looks in commit messages, but commits with ticket identifiers in the commit message can still fail the “use of branches” and “use of pull requests” scorecard checks in this report if they are on a main/master branch or not part of a pull request because they bypass the change control process.


### Does the report handle squash and rebase merges?

Yes, the report properly follows commits through squash and rebase merges using metadata available in pull request records so that they are treated the same way as regular merges. Code written in squashed or rebased commits will be checked for use of pull requests and ticket traceability.


### How does the report handle Git flows with multiple levels of pull requests?

For Git flows with multiple levels of pull requests, like having a side branch that is merged into a feature branch, then into development, and finally into main/master, the report searches for ticket identifiers in all pull requests until the code reaches an integration branch.

In the above example, if the first side branch pull request does not have a ticket identifier, but the PR from the feature branch into development does, then commits on the side branch will be properly counted as linking to a ticket.

However, if the feature branch PR also does not have a ticket, but the PR from development into master mentions some ticket in the body, then the side and feature branch commits will _not_ count as linking to a ticket because they did not have a ticket before reaching development – an integration branch associated with multiple features. In this scenario, mentions of tickets when merging from development to master are disregarded because it’s unclear which specific commits they are associated with.


### What version control systems are supported?

minware currently supports GitHub, GitLab, Bitbucket, and Azure DevOps Git version control systems.


### What ticketing systems are supported?

minware currently supports Jira and GitHub Issues as ticketing systems.


### How are deleted or moved tickets handled?

The report is currently unable to identify code that is linked to a ticket that no longer exists at its original ID because it has been deleted or moved. Deleting tickets is generally an anti-pattern and instead they should be resolved as “won’t fix” or a similar status to preserve traceability.


### How is code from bots or outside contributors treated?

This report excludes commits from bots and users outside of your organization in forked repositories so that they don’t count against the metrics.


Code/Ticket Traceability Report Screenshot

Code/Ticket Traceability

Track how consistently code is traceable to tickets via linked pull requests.

Capitalization

KPIs

Tickets

The sprint completion trends report shows you how teams are trending toward their sprint commitment over time to help identify issues with scrum adoption and agile sprint practices.

The report highlights several scrum anti-patterns. First, it shows you what portion of points or tickets completed in the sprint have rolled over from multiple sprints. This can help to identify teams that struggle to start and finish tickets within a single sprint and expose long ticket lead times due to slow QA or deployment stages that prevent tickets from wrapping up in one sprint.

The report also breaks out points or tickets completed in a sprint that were added after the sprint began. A large amount of work added after sprint start indicates that teams have a high burden of unplanned or interrupting work that may impact their ability to deliver on planned roadmap commitments.

Finally, the report shows the total amount of work completed relative to the initial sprint commitment so that you can quickly identify teams that are either struggling to estimate properly or having issues completing their planned work due to other factors.



Sprint Completion Trends Report Screen Shot

Sprint Completion Trends

View trends for points completed, rollover, and late additions vs. sprint commitment by team.

Agile

Scrum 

The project cost allocation report automatically calculates where people are spending their time based on a combination of signals from assigned tickets and coding activity linked to tickets.

The report displays the total amount of time spent on tickets aggregated by their project, as indicated by the parent ticket, which is often referred to as an epic.

You can easily customize the report to add grouping by team or person to see more detail about how to allocate costs.

The report displays time spent in developer-months to make it easy to use the output of this report for allocating development costs in accounting system journal entries by multiplying the developer-months by salary costs.


Project Cost Allocation Report Screen Shot

Project Cost Allocation

View time spent on each project to see where your development costs are being allocated.

Costs

Projects

The bug management report tracks how consistently teams are following best practices for managing bugs, and the total portion of time they spend on bug fixes.

First, it looks at whether each project has a system in place for indicating bug severity and if bugs are being filed with non-default severity levels, which is important for providing visibility into the impact of bugs.

Next, the report looks at what portion of new bugs are being fixed within 30 days. If this metric drops too low, it can indicate that the team is deliberately sacrificing quality to maintain their feature velocity.

Finally, the report measures the total amount of time that the team spends on fixing bugs. This can help highlight teams who spend too much time fixing bugs and may benefit from investments in test coverage and infrastructure to reduce the bug load as a portion of overall work time.


Bug Management

Track how consistently teams manage bugs and their overall bug fixing load.

Bugs

Quality

The Change Control Compliance report automatically calculates the percentage of time where work is done in compliance with the following change control best practices: use of branches, use of pull requests, and code reviews.

The Change Control Compliance report displays the percentage of time spent spent in the following ways:

  1. On commits in a non-main branch
  2. On branches merged through a pull/merge request
  3. On merged branches that received a code review

You can easily customize the report to filter by team or person to see more detail on how well various groups perform on these metrics.

Adhering to these best practices results in the following benefits:

  1. Shared knowledge across the team
  2. Improved code quality, security, and performance
  3. Auditability of code changes for compliance purposes

This report is useful to team leads, engineering leaders, security teams, and anyone interested in how well the organization complies with change control best practices.

Change Control Compliance Report Screen Shot

Change Control Compliance

View the percentage of time where work is done in compliance with change control best practices.

Compliance

Change Control

The Sprint Best Practices report automatically calculates information about Sprint best practices in terms of how development time is spent on tickets that adhere to best practices. 

Development time is calculated by allocating work hours between commits to the commit that follows. So, if you work 9-5 and commit at 1 PM and 5 PM, the 5 PM commit would be counted as one half day of development time. 

The Sprint Best Practices report displays the following information about how development time is spent:

1. **Ticket Estimates** - The portion of time spent on tickets that have estimates. Estimates are important. Without an estimate, it is difficult to have any expectations about how long a ticket will take and proactively break down tickets that are too big. The estimate can be a story point estimate or a time estimate.
2. **No Omnibus Tickets** - The portion of time spent on tickets that are “small” (defined as less than 5 development days). Large tasks are the enemy of productivity. Big tasks make it harder to understand the status of work, are difficult to estimate, and pose a greater risk of not having a clear definition of done.
3. **On-Sprint Work** - The portion of time spent on tickets that are in the active sprint. It is important that developers primarily work on tickets that are in an active sprint rather than working off-the-book tickets. If people don't work in the sprint, then it is difficult to predictably meet expectations.  
4. **No Multi-Sprint Rollover** - The portion of time spent on tickets that have active work in no more than two sprints. It is normal for some tickets not to finish by the end of a sprint and spill into the next one. Tickets may also get bumped from multiple sprints before work starts. However, once work begins on a ticket, it is a problem if it spans more than two sprints. ​​ In addition to the ticket likely being too big or having flow efficiency problems, this means that sprint commitments are unreliable and defeats many of the benefits that sprints provide.
5. **Stable Sprint Scope** - The portion of time spent on tickets that were in the sprint at the beginning. An issue that can disrupt sprint reliability is when teams are inundated with last-minute requests, urgent bugs, or new work that comes up due to lack of internal planning. This leads to the original sprint work getting pushed back, which erodes the reliability of sprint commitments.

You can easily customize the report to filter by team or person to see more detail on how well various groups perform on these metrics.

This report is useful to engineers, team leads, engineering leaders, scrum masters, and anyone interested in the health of Sprints.

Sprint Best Practices

View information about your sprints relative to the best practices of running sprints.

Estimates

The Work Batch Size report automatically calculates information about the amount of development time put into each branch, ticket, and epic.

Development time is calculated by allocating work hours between commits to the commit that follows. So, if you work 9-5 and commit at 1 PM and 5 PM, the 5 PM commit would be counted as one half day of development time.

The report shows three things:

1. The percentage of time spent on small, feature-specific branches.
2. The percentage of time spent on tickets with less than one week of development work.
3. The Dev Work Days associated with Epics.

You can easily customize the report to filter by team or person to see more detail on how well various groups perform on these metrics.

The scorecard metrics use a threshold of 5 dev days for considering a branch of ticket to be “small.” The reasoning is that with a two week sprint, a ticket or branch that takes more than one week of active development time will take up more than half the sprint and should be broken down into smaller tasks.

There is no threshold associated with epics, but you can sort the results to view the largest epics with this report.

Smaller is almost always better when it comes to batch size, and these signals provide important information about batch sizes:



1. A high number on Task Specific Branches indicates that branches have small changesets. This makes it easier to review code, have a working central branch for features/projects, and track which tasks are associated with each branch.
2. A high number on No Omnibus Tickets indicates that tickets are generally small and require less than one week of work. Small tickets are easier to understand and estimate, and have a higher chance of being delivered as expected. 
3. Epic size is important as well. Similarly to small tasks, small epics are easier for everyone to manage.

This report is useful to engineers, team leads, engineering leaders, and product managers to reason about the size of batches of work moving through the system.


Work Batch Sizes

View information about the size of tickets, branches, and epics.

Workflow

Epics

The Context Switching report automatically calculates the percentage of time spent focused on a single ticket (Flow Efficiency) and how well ticket statuses are kept up to date (No Stale Tickets).

Flow Efficiency is important and is worth explaining: if a developer marks a ticket as “In Progress” this morning and sets it to “Done” tomorrow morning but spends half of that time committing against a second ticket, they would have a Flow Efficiency of 50% for the day.

The report displays the percentage of time spent in the following ways:

1. Focused on a single ticket. 
2. On tickets that are marked as In Progress and receive commits at least weekly

You can easily customize the report to filter by team or person to see more detail on how well various groups perform on these metrics.

These signals provide information about the health of the development process:

1. High Flow Efficiency indicates a development process with little context switching so that developers are focused on one thing at a time. 
2. High “No Stale Tickets” indicates that ticket statuses are kept updated and that developers are regularly working on the in-progress items

This report is useful to engineers, team leads, engineering leaders, and anyone interested in the health of the development process.

Context Switching

Understand how focused your development activities are.

Overhead

This report was inspired by Uber's engineering metrics dashboard, described in detail in [this post from The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/uber-eng-productivity).

The five metrics covered in this dashboard include:
- Number of pull requests merged per developer
- Time from PR open to review to merge (Uber's dashboard only shows from open to merge, but we find it helpful to have a more granular breakdown.)
- Code review thoroughness (Uber's dashboard only shows review count per engineer, but we believe the more important number is ratio of pull requests have a review and where the review is thorough.)
- Active coding time per engineer compared to all work time (described as focus time per engineer in Uber's dashboard)
- Time from PR merge to launch (included next to the PR open to review to merge metrics)

Inspired by Uber's Dashboard Report Screen Shot

Inspired by Uber's Dashboard

See how your team performs on Uber's engineering dashboard metrics.

The kanban essentials report tracks [4 key kanban metrics](https://www.atlassian.com/agile/project-management/kanban-metrics) recommended by Atlassian. These metrics will ensure that work is flowing efficiently through your kanban board and help you quickly spot bottlenecks. The four key metrics in this dashboard are the following


### Work in Progress

This shows the number of tickets that are currently in an in-progress state. Simple math dictates that the more things you’re doing at the same time, the longer each one will take. You should strive to keep work in progress to consistently low levels by eliminating wait time and bottlenecks that cause the team to start on the next task before the last one is complete.


### Ticket Cycle Time

Cycle time is the time between work starting on a ticket and the ticket being marked done. It measures how quickly the team is able to handle each ticket. You should ideally keep cycle times consistent and work to decrease them by eliminating roadblocks that cause wait time where there is no active work on a ticket. You can spot problems by looking at tickets with abnormally high cycle times.


### Ticket Lead Time

Lead time shows the total time from when a ticket was created to when it was marked done. Essentially, it is cycle time plus queuing time – that is, the time before the team starts work plus time after the team starts work. When used in conjunction with cycle time, you should look for large discrepancies where tickets are backlogged for a long time, leading to higher lead times than cycle times. This can indicate that the team is overloaded or blocked from starting work on a ticket.


### Throughput

Throughput is simply the rate of ticket completion. Ideally, throughput should be consistent over time. If it’s not, that may indicate that teams are doing work in batches, which is less efficient than working on tickets sequentially – also known as single-piece flow in lean terminology.

You should also look at whether the team’s throughput is comparable to the rate of work coming in. If it is consistently less, then lead times can balloon due to increased queuing time.

Kanban Esssentials

Track essential kanban productivity metrics related to throughput, work in progress, and cycle/lead time.

Kanban

The uptime dashboard tracks time spent with open high-priority issues. It provides metrics showing both the highest priority (e.g., P1) and a second-tier high priority (e.g., P2).

The dashboard helps you visualize issues that cause downtime by team, issue type and ticket, including a breakdown of how long each high-priority ticket was open.

This report helps you monitor the impact of quality problems across a complex organization with multiple teams and track how well you are doing in one central dashboard.

Uptime and downtime metrics are essential KPIs for ensuring that your teams avoid quality problems with strong test automation, and are able to fix them quickly once they arise.

The difference between this report and what you might see in a system like PagerDuty, OpsGenie, or AWS CloudWatch is that it tracks outages at the ticket level based on data from Jira or other ticketing systems.

Oftentimes non-ticket uptime metrics don’t capture the full scope of outages since they may start prior to alarms going off, or not be fully resolved until tickets are marked done, which can happen after alarms subside. 

Organizations also sometimes have high-priority issues that don’t trip any alarms at all, which makes a ticket-based uptime dashboard critical for comprehensive observability.


Uptime Dashboard

Monitor time with open high-priority issues by team and ticket.

This report offers the four classic DORA metrics, plus lead time at the ticket level to give you a holistic view of your team’s delivery performance.

The four classic DORA metrics are:

* **Deployment Frequency** - Measure how frequently your team deploys to production. Strong numbers here of one or more deployments per day indicate a healthy build and deployment process with a high degree of automation.
* **Lead Time for Changes** - This metric is computed as the average time from first commit to deployment by pull request (PR). It indicates not only the health and frequency of the deployment process, but also that changes happen in small pull requests that are reviewed and merged quickly. This report additionally shows a breakdown of lead time by stage, including first commit to PR open, PR review, PR merge, and deployment.
* **Change Failure Rate** - This number shows how much of the time a deployment results in a high-severity incident. This report computes change failure rate by dividing the number of new high-priority tickets by the number of deployments in a given time period. This metric is a good indicator of code quality, change complexity, and test coverage.
* **Time to Restore Service** - Also known as mean time to restore (MTTR), this metric shows the average amount of time it takes to resolve an incident once it occurs. It is measured by the time from creation to completion for high-priority incident tickets.

This report also provides a bonus metric: **Ticket Lead Time**. Pull request lead time is important, but it doesn’t show how long it takes for customers to _see value_ for more complex tickets with multiple pull requests. Ticket lead time gives you a more clear picture of how long it takes to deliver finished features.


DORA Metrics

Track the four classic DORA metrics plus ticket lead time.

This report shows you key project completion trajectory metrics all in one place.

First, it displays the total scope of an epic in story points so that you can easily see scope creep over time.

It also shows the burndown and burnup of epic story points that have been completed and are still remaining as the project progresses.

Finally, and most importantly, it also shows you how much development effort has gone into the project. It displays dev effort side-by-side with story point completion so that you can easily spot changes to velocity, which may indicate technical debt or other blockers.

Together, these metrics help you assess when a project is likely to complete and identify problems early before they result in missed deadlines.

With the inclusion of dev days, you can quickly tell whether drops in project velocity are a result of estimation problems, or if developers have simply spent less time on the project, possibly due to distractions or work misallocation.

The report also lets you drill down into each metric by person so that you can tell who has the most workload, and is joining the project or being pulled away.


Project Completion Tracker

See project completion trajectory at a glance with story point burndown, scope creep, and dev effort in one place.

This report lists all of the available [minQL](https://www.minware.com/docs/overview/minql) properties in your organization’s data, and lets you inspect their values.

It covers four main primary object tables: `ticket`, `branch`, `person`, and `team`.

First, this report shows each of the names you can use when using `.get('<name>')`, `.duration('<name>')`, or `.onChange('<name>')` to access properties of these four objects, along with a count of objects in your organization having a non-null value. This list includes any custom fields you have added in Jira or other ticketing systems.

Note that if there are duplicate custom fields with the same name in your ticketing system, you may see different properties like `priority` and `priority_12345`. This can occur when importing data tickets from another Jira instance or deprecating and replacing a custom field. You will have to inspect the values and counts to see which one is the one you want.

Next, the report shows available events for `ticket` and `branch` objects that you can reference in metrics using `ticket.event('<name>')` or `branch.event('<name>')`.

Following the property names, there are widgets that can display values of specific properties. To change the property for which values are displayed, click on the widget and edit the property name filter. These widgets help determine which values are available when using different properties.

Finally, the report shows values of the `subType` field associated with events, which you can again filter by event type by clicking on the widget and adjusting the event name filter. These values can further be used to filter events with a `.filter()` expression.

minqL Property Reference Report Screenshot