How to Measure Developer Throughput to Maximize Results?

When you overlook agile software development principles or say, when it’s not done right, Agile can open up multiple doors to process inefficiencies. Meeting creep, scope creep, ineffective communication, and so forth. Process inefficiencies often morph into engineering inefficiencies. The outcomes could be horrible. Stifled developer productivity, broken developer flow state, low dev throughput, slow development velocity, piling technical debt, and super derailed project timelines, among multiple others. 

Team Hatica hopes none of this is relatable to you.

However, as per the State of Agile, last published in 2023, 28% of enterprises & teams aren’t satisfied with Agile. Or let’s say, they failed to tap into the potential of the agile software development approach. 

These organizations are often data-deficient teams, who are neither tracking any key engineering metrics and KPIs nor equipped with a potent engineering analytics tool (say ‘Hi’ to Hatica). 

Result? 

No workflow visibility, unoptimized processes, and operational setbacks that are detrimental to engineering excellence. 

Solution? 

Start tracking. 

If you’re an engineering leader, equip yourself & your team with engineering analytics tools that help you gain better visibility into your engineering processes. Embracing tools that help teams be more project-aware is fundamental to Agile. In fact, 37% of enterprises say that they are satisfied with agile because of increased visibility into the software development lifecycle.

So, the big question is, how do you gain SDLC visibility? 

Request an invitation to explore Hatica. 

Hatica is an engineering analytics tool that helps you gain unparalleled visibility into your engineering workflows by collating 130+ engineering metrics from all the workspace tools your engineers use. 

You can visualize all 130+ metrics in visually aesthetic and actionable Hatica dashboards. This enables you to identify bottlenecks in your SDLC processes, and accordingly mitigate them. You need to use Hatica goals & optimize the metrics to unlock engineering excellence.

Among all these metrics, Developer throughput is a key engineering metric that you should look to track & optimize for improving workflow visibility. But there is a catch. A singular focus on optimizing developer throughput can be counterproductive for your teams. 

So, what’s the right way?

Well, read this insight and you’ll understand-

• What’s developer throughput?

• Why does it matter? 

• How to measure dev throughput?

• How can you optimize developer throughput the right way using the dev throughput Hatica dashboard?

What Is Developer Throughput?

Developer throughput in software development is the amount of work done by an individual developer in a sprint, in a week, or in a given time frame.

Wait, does this not sound too similar to the definition of development velocity?

It does. 

However, there is a difference between developer throughput and development velocity. They are two different things.

Development velocity is the amount of work completed in a given time period. It is an engineering metric teams rely on to predict feasible software delivery timeline for ongoing and future projects. 

However Developer Throughput is gauged to track development velocity along with process efficiency including other parameters such as coding days, code churn breakdown, active contributors, etc. It is a way to track progress on multiple projects and understand how well your processes are working. 

There are different aliases for developer throughput- engineering throughput, dev throughput, and some prefer just ‘throughput’.

Why Should You Measure Developer Throughput?

Is your team delivering new code? Is it busy working out operational hassles? Are developers continuously working on code refactoring? Just delivering backlogs is not enough. Staying busy alone does no good. Making the code accessible, usable, and reliable is what matters. Just measuring engineering metrics & KPIs is not enough. Harnessing metrics to identify bottlenecks, and do course correction for superior organizational performance, team performance, and employee well-being is what solves the purpose.

Why measure developer throughput, you ask?

• You measure developer throughput and look at it holistically with a couple of other engineering metrics, such as code churn, PRs merge rate, coding days, etc., which helps you assess if developers are facing any challenges in creating value for the end users. 

• Substantial deviations in developer throughput, dips, or spikes, could be a hint of inefficient planning & work allocation. You can fetch these information at a detailed level from the Resource Allocation dashboard and at an aggregated level from Dev Throughput dashboard as well.

• The dev throughput ebbs & flows are an early alarm. A timely analysis could help you zero in on operational bottlenecks (root cause) to innovation and/or value creation. Unless you measure, it is going to be difficult to discover and mitigate the challenges?

• Besides, it helps you inject predictability into software projects and helps you in effective & efficient project planning.

• Pairing up developer throughput with value stream metrics like deployment rate, and performance metrics like MTTR, code churn, change failure rate (CFR), etc., helps you unlock engineering efficiency.

Hatica Dev Throughput dashboard gets you details such as: active contributors, PRs created vs merged in the time frame, PR Throughput, coding days, code churn breakdown as to identify where are developers involved over a given period. 

The dashboard also presents a code churn breakdown pattern over weeks and sprints along with the Productive Throughput and Efficiency trend for engineering leaders to realize system efficiency and effectiveness. 

How To Measure Developer Throughput?

The math here is simple. 

While planning the sprint, you must have assigned story points to each of the backlog items. Just sum up the story points for all the backlog items a developer completed/delivered in a given time frame (a week, a month, a sprint). That’s the dev throughput for the respective developer.

Hatica integrates with your project management tools (Jira, Asana, ProductPlan, ClickUp, etc.) where you define these story points, your issue management tools (PagerDuty, OpsGenie, etc.), your version control system (GitLab, Bitbucket, etc.), and your repositories to collate relevant data for calculating developer throughput. Here’s a complete list of Hatica connectors, aka integrations.

Let’s assume-

• Backlog items for a project are B(1), B(2), B(3) … B(n). 

• The respective story points (SP) for backlog items are denoted as SPB(1), SPB(2), SPB(3) … SPB(n). 

• The project is divided into equal sprint lengths of 3 weeks each.

Then,

• If B(1) and B(2) are delivered in first week of the sprint,

Weekly Dev Throughput for the week = SPB(1) + SPB(2)

• If B(3), B(4), and B(5) are delivered in the next two weeks,

Sprint Dev Throughput = SPB(1) + SPB(2) + SPB(3) + SPB(4) + SPB(5)

• If B(6) and B(7) are delivered in the 4th week,

Monthly Dev Throughput = SPB(1) + SPB(2) + SPB(3) + SPB(4) + SPB(5) + SPB(6) + SPB(7)

Note: As mentioned on the Scrum website, while calculating throughput, don’t consider subtasks as separate work items.

How Does Hatica Help You Harness Developer Throughput The Right Way?

Let’s understand this with 2 example cases.

Case 1: Let’s say, individual dev throughput for John nosedived in the last week for an ongoing sprint. John is a backend Python developer working on a healthcare EHR application. 

As an engineering manager, who is keen to help John, you may want to take a look at PRs created vs PRs merged.

• If the PRs created are high and the PRs merged rate is low, you need to see whether the rework time is high, or the PRs reviewed are low. A high rework time would mean that the code quality is slowing down John’s throughput. A low number of PRs reviewed signals broken code review processes. 

• If PRs created themselves are low, you would want to further diagnose and analyze Maker time, Coding days, Involvement, Quiet days, Issues without PRs, and Lines of code metrics for John to gauge what’s going wrong.
  Is it low maker time? 

Maybe John is a victim of meeting creep?

• Is it low coding days? 

Maybe the backlog item was too complex for John? If yes, then diagnose further whether this is a case of poor workload allotment & planning, or if John is genuinely struggling to deliver. You may also want to look at the Dev throughput for other members of the team to cross-check that it is just an individual problem and not a team phenomenon. Otherwise, unclear requirements could be a probable reason for low throughput.

• Is it high involvement? 

Is John excessively involved in reviewing PRs? Again, this could be due to broken code review processes, which may need your attention.

• Is it low ‘quiet days’? 

Probably, John needs more uninterrupted time and a better work-life balance.

• Are the issues without PRs that John has committed too high? 

Well, this could be a case of poorly managed scope creep. Look at Lines of Code (LoC) metrics by John, and if that too is high, it could indeed be a scope creep issue.

You need to continue with the root cause analysis (RCA) process, until you’ve figured it out. Accordingly, you can find a solution.

Case 2: Let’s say, individual dev throughput for John unexpectedly skyrocketed in the last week for an ongoing sprint. John is a backend Python developer working on a healthcare EHR application.

As an engineering manager, who is keen to help your team be at their best selves, you would want to look at code churn, coding days, maker time, involvement, quiet days, and so on.

• If code churn is high, it is an indication John is pushing suboptimal code to production. This also signals that subpar code is made through the code review, and hence, the code review process is broken too.

• If coding days, maker time, and quiet days are high, or if involvement is low, then it’s possible that the engineering processes in your organization are more streamlined. 

• Maybe, the throughput spike is because of recent investment into AI tools for developer productivity?

• Or maybe, inculcating DevOps culture is finally bearing its fruits?

• Or maybe, it’s because you’re using Hatica the right way to identify & fix bottlenecks in your engineering processes?

What??

It’s not hard selling (smirk).

Our customer, BobbleAI improved delivery velocity by 220%.

Anyway, the point is that you must measure developer throughput to diagnose what’s wrong, and to maximize what’s working in favor of your engineering teams & projects. Helping developers unlock their full potential is what matters in the end. Because only that will fuel more innovation, more value creation, more happy customers, and more revenue.

Hatica’s Developer Throughput dashboard helps engineering managers and tech leadership to take a comprehensive look at these metrics both at individual developer level as well as at team level (in the form of aggregated data). 

The same data can then be sliced and diced as per project level or teams that are clustered into different geographies. This makes it easier to identify patterns, loopholes, inefficiencies accordingly and not implement a blanket approach to fix what is not broken elsewhere in the organization.

Reading recommendations:

1. Dev Throughput is an engineering velocity metric. You must read Hatica Insight on “velocity metrics for improved engineering efficiency” to understand how you should use velocity metrics, and more importantly, how not to use velocity metrics. Teams often go wrong with velocity metrics. They tend to use it as a performance metric. It could be terrible if you use dev throughput as developer performance metrics. You must not use velocity metrics in isolation to measure performance. But if you bring quality & reliability metrics in the same frame, it’s a different game. Find more details in the article.
2. Development velocity is akin to dev throughput but at a team level. You must read Hatica Insight on “What is development velocity and how to improve it” to understand in a more elaborate way why development velocity metrics could be a game-changer for engineering teams. Velocity metrics can help make projects predictable. They empower you to effectively plan projects, and efficiently allocate and utilize engineering resources. Find more details about the factors that stifle development velocity metrics like dev throughput, and how you may improve velocity metrics by rooting for developer experience (DevEx), developer’s psychological safety, and data & metrics driven engineering approach, among multiple other factors.

Keep innovating. 

Try Hatica, today. It’s FREE to get started. Or else you can also request a demo to talk to our productivity experts.