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.