Browse minware's reports on cycle times, context switching, work-in-progress, DORA metrics and more to ensure that your team is working efficiently and free from interruptions.

Improve software development workflow with minware's reports on context switching, cycle times, work-in-progress, DORA, and more.

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.

KPIs

Workflow

Overhead

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

Agile

Tickets

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.

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 scores for large branch rate (LBR) and large ticket rate (LTR), which measure the amount of development effort that goes into large branches and tickets, which is less than 10% for top-performing teams.

Additionally, the report lists the largest pull requests, tickets, and epics based on the total amount of development work so that you can diagnose outliers and fix the root cause of issues related to large work batches.

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 overly large tickets, branches, and epics, which can impact development efficiency.

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.

Report Templates: Workflow

Work Batch Sizes

Context Switching

Inspired by Uber's Dashboard

Kanban Esssentials

DORA Metrics

Didn’t find what you were looking for?

Page Load Failed