Ticket creation - Ticket creation helps to identify who drives the requirements of a team. This can be from the team itself or external.
Sprint completion - Completion rate indicates how well a team is in executing their planned work.
Tickets carried over - Highlights what is happening to tickets not completed in their first sprint.
Sprint stability - Stable sprint requirements provide a team with a stable goal. Changing requirements mid-sprint has an impact on a team's ability to complete the agreed scope. the later that the changes are made.
Review Speed - Review speed measures the time it takes to review a Pull Request. If review/approval is slow, the context is lost for the author.
PR Size - Small pull requests are easier to review, making it more likely for code to be thoroughly reviewed before approval. Large pull requests tend to be glazed over and rubber stamped.
Files per PR - A large number of modified files per PR can make the code review more complex, requiring the reviewer to have more context. It can also indicate a complex architecture.
PR Approval rate - A quality measure of a teams review process.
Time to fix a broken build - The time between a build failing and being resolved is a high-risk time frame due to that deployments are blocked and fixes cannot be pushed for customers.
Automated testing - A higher amount of testing during deployment, and earlier in the process will lead to more successful builds and therefore less rework and better deployment health.
Commits per build - A large amount of commits per build makes it harder to detect the reason for build failures.
Balanced communication - Balanced communication ensures all team members are involved in communications.
Responsiveness - Members of a responsive team are able to remove impediments and progress with their work quicker than less responsive teams.