Straightforward Metrics for Engineering Teams

Don’t get lost among a myriad of charts and numbers.

Engineering Success starts with the right metrics. SourceLevel provides essential and actionable metrics for engineering leaders.

    What are Engineering Metrics?

    Engineering Metrics are measures used to understand the software development workflow from an engineering perspective.

    What are the benefits of Engineering Metrics?

    Keep an eye on
    Work in Progress

    Aging Time to Merge

    The Aging Time to Merge visually aggregates open Pull Requests into three phases:

    1. Open
      the Pull Request was opened, and the team has not interacted or reviewed it.

    2. Engaged
      one or more people commented on the Pull Request. However, it’s not approved, nor changes were requested.

    3. Reviewed
      the Pull Request received at least one review (be it an approval or request changes)

    Understand the team’s Engagement

    Engagement Volume

    SourceLevel breaks down the team’s engagement into actions. The chart measures the volume of Pull Requests opened in a week in bars. The lines represent the number of comments, approvals, and request changes in the week.

    It’s an excellent tool to understand how engaged the team is. The number of comments should be proportional to the team’s size. Besides, the chart is useful for monitoring rework. A high number of request changes usually indicates code needs severe interventions.

    Time to Engage

    Accelerating deliveries requires measuring how much time the team spends on each step of the development flow. The Time to Engage chart displays how much time it takes for the first engagement to happen. Be it a comment, an approval, or a request change, the first action defines the starting point of the engagement.

    The chart displays the 75th and 95th percentile of this number. We don’t use medians. It means that SourceLevel calculates the Time to First Engagement taking into account 75% and 95% of Pull Requests, respectively.

    Accelerate and increase Deliveries

    Throughput with Time to Merge

    Throughput is the number of Pull Requests merged in a week. SourceLevel ignores closed Pull Requests as they didn’t add value for the final user. The Time to Merge tells how many days each pull request remained open.

    Finding the correlation between the amount of work done by the time it took is the best way to determine what accelerates or slows down the process. Plus, the numbers can give you the confidence to forecast future deliveries.

    Time to Merge Histogram

    Histograms are an accurate representation of the distribution of numerical data. In practice, it’s a bar chart that shows the number of merged pull requests (Y-Axis) grouped by the number of days they stayed open (X-Axis). The higher the bars on the left, the faster pull requests get merged.

    Examples of Engineering Metrics


    Why doesn’t SourceLevel measure averages?

    SourceLevel prefers using percentiles instead of averages because averages hide too much information when working with metrics that vary too much, such as velocity.

    SourceLevel provides two percentiles for comparison: the 75th and 95th.

    What do 75th and 95th percentile mean?

    Let’s see an example to understand better what they mean. If your organization’s Time to Merge is 14 hours, it means that 75% of all Pull Requests merged in the period was merged up to 14 hours.

    The same applies to the 95th percentile. So whatever the metric is, the 95th percentile means that 95% of all analyzed data are below that number.

    Why does SourceLevel use 75th and 95th percentiles?

    The 75th percentile gives more visibility to the engineering team. Managers don’t want an average team. They want a team to be as productive as it can.

    The 95th percentile shows an even bigger picture of the teamwork, excluding the bottom 5% (outliers).

    See SourceLevel in action with a guided demo!