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.

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 

Tickets

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.

KPIs

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.

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?