Parent page: [X - Engineering KPIs ](https://mui-org.notion.site/b70113a10e5749f286149036292b07cc)

What are Engineering KPIs?

Key performance indicators are used to monitor the efficiency of the team and identify potential bottlenecks ahead of time.

This page contains a subset of what is listed under the company KPIs page. There’re may also specific team-related KPIs.

Types

• Lagging: measures the actual impact after it happens. For instance, revenues tend to grow after npm downloads do.
• Real-time: measures the actual impact. For instance, at the product level, our mission is fulfilled when people deploy to production, using our product over alternatives.
• Leading: measures the actual impact before it happens. For instance, I believe we have been able to use survey data to steer the above metrics in the right direction.

Legend

📊 indicates that the KPI is operational and is embedded in the handbook next to the definition and shown publicly.

🔗 indicates that the KPI is operational and there is a link from the handbook to another system. This may be because the KPI cannot be public or because it isn't possible to embed it yet.

🚧 indicates that the KPI is in a WIP: work in progress status estimated to be shipped in any system within the month. When using this indicator, an issue should also be linked to this page.

🐔 indicates that the KPI is unlikely to be operationalized in the near term.

Engineering KPIs

• HEAD CI success rate 🔗
  • Type: Leading
  • Why? Measures the stability of the MUI X projects HEAD branch success rate. This is about measuring flakiness.
  • Target: above 95%
  • Health:
  • Value
    • https://app.circleci.com/insights/github/mui/mui-x?reporting-window=last-30-days
• HEAD CI median time to completion 🔗
  • Type: Leading
  • Why? The shorter the feedback loop is, the smaller the PRs we open are, the more granularity, the more we increase the code quality.
  • Target: below 15 minutes
  • Health:
  • Value: https://app.circleci.com/insights/github/mui/mui-x?reporting-window=last-30-days
• PR CI median time to completion 🐔
  • Type: Leading
  • Why? The shorter the feedback loop is, the smaller the PRs we open are, the more granular we get in our work, the more we increase the code quality.
  • Target: below 15 minutes
  • Health:
  • Value:
• Time to the first feedback on PR 🔗
  • Type: Leading
  • This is measured between the timestamp of the first review request and the first comment.
  • Why? Reviews help others move faster, unlock them, create a more enjoyable work environment, and reduce context switching for developers.
  • Value: https://ossinsight.io/analyze/mui/mui-x#issue-first-responded-time
• Time to the feedback on PR 🔗
  • Type: Leading
  • This is measured between the timestamp of the review request and the next comment. This is based on the user who got the review request.
  • Why? Same "Time to the first feedback on PR" but so we don't ignore follow-up answers.
  • Value: https://app.swarmia.com/insights/code/reviews?teamId=03835c74-b79f-4232-8089-38f5d2d44074
• Number of collaborators per pull request 🐔
  • Type: Leading
  • Why? Have more knowledge sharing
  • Value: