Sprint Metrics

Sprint metrics can help you plan and deliver on sprints more effectively, including backlog grooming and story hygiene. These metrics can help you address business problems like:

  • Do teams consistently deliver on sprint plans? If not, why?

  • What is the impact of creep or un-estimated tickets on plans?

  • Are teams overburdened or underutilized by the sprint plans?

Sprint metrics use cases

These examples show how you can use sprint metrics to measure team performance.

Measure team performance in recent sprints

Use the commit done ratio to check the team's performance on recent sprint plans. Compute this metric as an average over the last 2 months or 6 sprints.

If the average commit done ratio over a long period of time is above 70 per cent, then the team is executing sprint plans well and could potentially take on more load. If the total done to commit ratio is above 120 per cent, then the sprint plans aren't making full use of the team's capacity.

A commit done ratio below 60 per cent indicates poor performance on sprint plans and room for improvement in sprint delivery. There are several reasons a team might perform poorly on sprint plans. Check for:

  • The impact of creep and context switching on sprint plans. Check the creep to commit ratio and the creep done to commit ratio. Creep that is consistently above 40 per cent could have an impact on sprint deliverables.

  • Vague requirements that cause rework and impact sprint delivery. Use an Issue Hygiene Report to check the sprint's Hygiene Score.

  • If none of the above apply, then the team may be consistently planning for more than they can deliver.

Here is a flow chart illustrating the use of sprint metrics for performance analysis:

Analyze sprint performance

This example analyzes team performance over a sprint, as represented by the following JIRA sprint report:

Ticket ID PointsStatusNotes

LO-1

2

Done

Completed in the sprint

LO-2

1 -> 2

Done

Points changed from 1 to 2 mid-sprint, completed in the sprint

LO-3

5

Done

Creep, completed in the sprint

LO-4

5

In Progress

Not completed

LO-5

1

In Progress

Creep, not completed

LO-6

1

Done

Completed outside the sprint

LO-7

1

To Do

Removed from sprint

The following table represents how the above JIRA sprint report is interpreted by SEI:

IssueStatusCommit pointsCommit done pointsDelivered pointsCreep pointsCreep done points

LO-1

Done

2

2

2

-

-

LO-2

Done

1

2

2

-

-

LO-3

Done

-

-

5

5

5

LO-4

In Progress

5

-

-

-

-

LO-5

In Progress

-

-

-

1

-

LO-6

Done

1

1

1

-

-

LO-7

To Do

1

-

-

-

-

Total

-

10

5

10

6

5

SEI uses the above points values to calculate sprint metrics ratios, generating the following sprint performance analysis:

MetricValueAnalysis

Commit done ratio

5/10=50%

Indicates poor performance on the plan.

Done/Delivered to commit ratio

10/10=100%

Indicates an overall good job delivering on commitments.

Creep to commit ratio

6/10=60%

Indicates too much creep in the plan.

Creep done to commit ratio

5/10=50%

Poor performance on the plan is explained by creep.

Use historical metrics for sprint prediction and performance assessment

You can use historical cycle time data and key metrics to evaluate a team's performance, predict the number of items that can be completed in the next sprint, enhance sprint planning, and improve overall efficiency.

Use Sprint Metrics Single Stat widgets to present sprint metrics or sprint metrics ratios on your Insights, such as the done to commit ratio, scope creep (unplanned work) ratio, sprint velocity, or creep to commit ratio.

After configuring the widgets, use the provided statistics to estimate the number of items for the next sprint, evaluate performance, and identify trends.

Sprint metrics reports

Use sprint metrics reports to analyze sprint and planning metrics.

You can use the Sprint End Date time range filter to limit data to the last few sprints. It is recommended to observe sprint metrics over 2 months or 6 sprints.

You can use the Sprint Report field to limit data to a selected sprint stream or sprint names with a common prefix.

Sprint Metrics Trend Report

The Sprint Metrics Trend Report is recommended for visualizing a time series trend of sprint metrics, like commit done points, creep points, or commit points.

Sprint Metrics Percentage Trend Report

Use the Sprint Metrics Percentage Trend Report to examine a time series trend of selected sprint metrics ratios. This report is recommended for visualizing changes in the commit done ratio, done to commit ratio, and creep to commit ratio.

Sprint Metrics Single Stat

The Sprint Metrics Single Stat widget presents a single sprint metric averaged over the selected time interval.

For example, the Sprint Metrics Single Stat widget can help you use historical metrics for sprint prediction and performance assessment.

Sprint Metrics Single Stat configuration options

  • Metric Selection: Select the sprint metric or sprint metrics ratio that you want to show on this widget.

  • Ideal Range: Define ideal ranges for metrics such as velocity points, commit ratios, and more. You can set upper and lower bounds to indicate acceptable performance ranges.

  • Sprint Creep Grace Period: Define a grace period during which any additional work or changes introduced at the beginning of the sprint are considered part of the original commitment rather than creep.

  • Additional Done Statuses: Specify additional ticket statuses that you want to consider equivalent to Done for metrics calculation.

  • Issue Management System: Select the issue management system from which to pull data for the widget. Available systems depend on your configured integrations.

To configure this report, Go to Sprint Metrics Single Stat.

Other sprint metrics reports

  • Sprint Impact of Unestimated Tickets Report

  • Sprint Goal Report

  • Sprint Distribution Retrospective Report

Jira Releases report

When setting up a workflow profile with Jira as the Issue Management Platform, you have the option to add a release stage. This enables you to generate the Jira Releases report on your Insight that helps you track the schedule of how features are rolled out to customers, i.e., track the release frequency on Jira.

On the Filters tab, you can specify the time range for measuring Jira releases and add criteria for retrieving Jira issues based on ticket resolution time.

You can add additional conditions to define what data feeds into this widget by creating inclusive and exclusive filters.

On the Settings tab, select the Jira-based velocity lead time profile for this report. Note that this widget can only be associated with a Jira-based Velocity Lead Time profile, i.e., a Velocity Lead Time type Workflow Profile with the Jira Releases stage enabled under the Lead Time configuration.

  • Sprint metric reports, only includes the issues that were both started and completed during the sprint timeframe.

  • If an issue is completed outside of the sprint, it is not included in the sprint metrics report for that specific sprint. Instead, the completion of the issue is reflected in the sprint where it was actually resolved.

  • If an issue is removed mid-sprint from the current sprint, it is not included in the sprint metrics report for that particular sprint. SEI excludes such issues from the calculation as it may affect the team's velocity and other related metrics.

Last updated