Browse minware's detailed sprint metrics, scrum reports, and agile dashboards which provide visibility into the software development process, making it easier to monitor progress and address bottlenecks.

Increase visibility into the entire SDLC with agile metrics, sprint metrics and scrum reports.

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 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. **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.  
3. **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.
4. **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.
5. **Sprint Completion** - The portion of story points or other estimate units completed relative to the original commitment.

In addition, this report shows a chart of sprint completion history relative to commitment including whether tickets rolled over or were added after the start of the sprint, making it easier to spot trends at a glance.

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 how well your team follows best practices related to running sprints.

Agile

Scrum 

Estimates

Tickets

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 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 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.

First, the report shows the total amount of work by ticket status (to-do, in progress, done) 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.

The report then shows a breakdown of completed points by assignee at the end of the sprint. You can drill down by clicking on a data point to see the total tickets committed and completed by each person during the sprint.



Sprint Completion Trends Report Screenshot

Sprint Completion Trends

View trends for points completed vs. sprint commitment by team and individual.

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: Scrum and Agile

Sprint Completion Trends

Sprint Best Practices

Work Batch Sizes

Context Switching

Inspired by Uber's Dashboard

Kanban Esssentials

Didn’t find what you were looking for?

Page Load Failed