What this section is for
Choose a team and dates to create a report with a fixed structure. It includes commits, pull requests, merged counts, time to merge and automatically identified highlights and risks. Add the team’s explanation before using the summary in a meeting or sharing it.
When to use
- At the end of a sprint, for the update that goes to people outside the team.
- When you need to save period results for a later comparison.
- Before a retrospective, so everyone starts from the same numbers.
Quick start
- 1Generate a report with start and end dates that match your sprint exactly.
- 2Check flagged highlights and risks, such as low bus factor or long time to merge. Look for the causes in the relevant sections.
- 3Keep reports for consecutive periods of the same length so you can compare results.
Key settings
| Setting | What it does | How to use it | Common mistake |
|---|---|---|---|
| Report period | The date range the report covers. | Align exactly to sprint boundaries and keep the same convention every time. | Changing period boundaries between reports and comparing the totals as if the dates matched. |
| Team | Whose activity the report includes. | Select the team whose work you are reporting. Keep the same data selection when comparing periods. | Creating a report for another team without checking the filter. |
Usage example
Scenario: You need a regular update on a two-week sprint.
- 1Create a report for the sprint dates, using the same date convention as before.
- 2Check the totals and explain what the team released, what got in the way and which tasks changed.
- 3Review flagged risks and note which were confirmed and what the team decided to do.
What this shows: You have a report in a familiar format with comparable numbers and the team’s explanation.
FAQ
Can I change what goes into the report?
Not here. The sprint report has a fixed structure. Custom Metrics lets you define formulas and assemble a different report template for manual runs.
Why do the risks look generic?
Risks are flagged using thresholds for metrics such as bus factor, commit distribution and time to merge. They suggest what to check but do not explain the cause. Review the source data and ask the team about the circumstances.
Tips
- Keep consecutive reports, including periods with failures, so you can compare them later.
- Add team decisions and next steps to the numbers. Metrics alone cannot show them.