There are many ways to develop engineering metrics. Ideally you need a representation of different aspects of the operational data such as throughput, quality and cycle time to name a few.
The goal of gathering this data is to define what a healthy and successful team looks like and to foster a healthy dialogue amongst the engineering team and with stakeholders. These metrics are helpful for conversations around planning, addressing technical debt, capacity to work on bugs, identifying bottlenecks and improving engineering efficiency. Metrics are a good way to also see how change affects the team’s execution.
Engineering metrics are project or team based and are not intended to track an individual's capacity or performance. It is important to note that if metrics are used punitively, these goals are hampered and the team psychological safety could be at risk.
As a manager you should ensure you are on top of your team's metrics, driving the right behavior, and understanding any fluctuations. Expect to be able to discuss your team's metrics with your manager on a weekly basis.
To access our current dashboard, please visit the GitLab Insight Quality Page. We are currently working to implement these graphs into the GitLab product.
regression:x.ylabel. It is possible that some regressions are not captured due to it not having a regression label.
We are currently working on including all of engineering's projects. The following projects included can be seen in this list.
We also capture data from our
https://dev.gitlab.org/ instance which currently includes the projects below.
The data from dev instance is only reflected in a few group level charts, see list of known issues below.
https://dev.gitlab.org/, only the 3 group-level charts below are reflected with data from this source.
If you or your team needs to include a new project in the metrics or add a new team, please create an issue in the GitLab Insights issue tracker.
We have a list of projects that are still not included in this issue.
Considering how one of our development department KPIs is to have a goal of 8 MRs per Engineer per Month, here are some steps on how to build your own custom team metrics dashboard on Periscope so that managers can better coach their teams to achieve the KPI target.
Note: These dashboards will be available internally to everyone at GitLab (as per default periscope permissions). Considering that the majority of engineer MR activity is public, we do not anticipate this being an issue. In addition, anyone that can view the dashboard will also be able to toggle the filter to see individual team member metrics. We purposefully do not chart all team members in a specific chart against each other because throughput is just one data point and is not a holistic evaluation of a team member's productivity/performance.
Note: MRs that are merged in dev.gitlab.org are not available in periscope: gitlab-data/analytics#2789
Note: These dashboards do not automatically refresh data. You'll have to either manually refresh the data or create an issue on the data project to request that your dashboard automatically refresh data
+icon on the right to create a new filter
Type in names and values
USERNAMEwith your team member's GitLab username.
Select Displayedunder your newly created filter to filter the results by your entire team
editbutton in every chart on the dashboard and replace every reference of
frontend_monitor_health_teamwith the name of your filter so that the dashboard is filtered by your results
What am I looking at?section so that it accurately reflects your team information