GUIDE

Developer productivity management:
a complete guide

How to build productive software development teams and track their progress
15-minute read

With the ongoing digitization across all industries, it's fair to say that most companies are becoming software companies. However, with this reliance on software to take companies to the next level comes a reliance on the people and the processes that build it. Because of this, developer productivity is becoming more and more central to business success.

But, what even is "developer productivity," and how can we encourage, measure, analyze, and manage it? In this guide, we'll examine what the software development community believes developer productivity is and how we can gain insight into and better manage our team's productivity.

Alright, let's get started!

What is developer productivity?

In everyday language, "productivity" is the ability to produce. In software development, developer productivity refers to a team's ability to achieve outlined business objectives through developing, improving, and maintaining software.

We surveyed developers to understand better how they viewed the concept of productivity in the context of software development. The overwhelming majority agreed that it is a "combination of processes and tools and people and skills."1 Despite this, the most common method of measuring productivity, and for a surprising amount of teams, the only method, is throughput (i.e., amount of units of work completed). There seems to be a discrepancy between how we define a developer’s productivity and how we measure it.

To better understand how we can measure and define dev productivity more comprehensively, let's examine what productivity experts call the SPACE framework.

The SPACE of developer productivity

In the world of software development, the SPACE framework is one of the most referenced frameworks for understanding what productivity in software development consists of and how to measure it. Developed by researchers at GitHub, Microsoft Research, and the University of Victoria, the SPACE framework suggests that there are 5 key elements we can use to guide, assess and measure dev productivity.2

Satisfaction and wellbeing: How well are developers’ needs met?

When we think of "productivity," it’s easy to think of humans as "cogs in the machine" that need to produce. This myth of "hustling" and burning yourself out at a job to be more productive has long been debunked. It turns out productivity and job satisfaction are strongly correlated – in our survey, 94% of respondents rated how important job happiness was to their productivity over an 8 out of 10.3

In other words, developers are people, not resources. They have needs and natural ebbs and flows in their productivity and shouldn’t just be milked for everything they’ve got – this can lead to burnout. Because of this, it's important to measure and encourage developer satisfaction and prevent developer burnout as a part of managing your team's productivity.

Here are some questions you can ask to determine developer satisfaction:

  • Is the team using all of their allocated vacation time (or an ample amount if it's unlimited)?
  • Do your developers feel comfortable speaking about their work capacity in your culture? (this can be determined by an anonymous culture survey)
  • How engaged and excited are team members about projects? (Providing devs with better projects has been proven to increase satisfaction, according to our developer happiness report)
  • How well-resourced is the team for what they are trying to achieve? (i.e. Is the team regularly having to work overtime to achieve goals?)
  • How satisfied is the team with the tools they have? (We recommend surveying the team every quarter to gage how they feel about their current tools)
  • Does your team feel like they have the opportunity to choose to work on projects that interest them?

Performance: Does the development team produce quality work that has a positive impact on the business?

The “performance” aspect of the SPACE framework refers to the development team’s ability to produce outcomes that provide value to the customers and the business. According to our survey, the #1 benefit of improved productivity is the ability to write quality code. In other words, are developers doing “meaningful and quality work”? Two elements make up performance:

Quality

Quality pertains to the work meeting a standard that the business, the customers, or both set. Quality-related metrics differ based on what the business objectives are. These are some examples of quality-related metrics that may define a team's productivity:

  • # of bugs found
  • Product loading speed
  • Time spent working on tech debt

Impact

“Impact” refers to the impact the work the development team completed has on the customers and the business. Some examples of metrics that may define the value a release has provided customers are:

  • Customer retention/churn rates
  • Average customer satisfaction scores
  • Average customer value (this metric’s usefulness varies by SaaS pricing model)
  • Time customers spend using the product or a new feature

Some examples of metrics that may define the impact the development team has on the business are:

  • Number of customer support tickets received since the release
  • Time spent onboarding new customers

Activity: How much does the team output in a given timeframe?

Quantity and speed

Quantity and speed refer to a certain amount of completed items in a specified time. Examples of business objectives measured by quantity completed include:

  • Deploying specific releases or a certain number of releases during a timeframe. (measured by # of pull requests merged, # of issues or story points complete)
  • Launching a release by X time
  • Address bugs reported within X timeframe

Communication and collaboration: How well does the team work together?

A team’s ability to communicate and collaborate together effectively greatly impacts its ability to stay productive. However, much of the work that goes into smooth collaboration and communication goes unnoticed and underappreciated.

Here are some quantitative and qualitative ways of measuring how effective your team’s collaboration and communications are:

  • The speed of handovers and pull requests
  • How much time is spent looking for documentation
  • Amount of time spent in meetings
  • Whether teams are implementing learnings from sprint retrospectives and reviews
  • Time tickets spend ‘in review’ or ‘in QA’

Tooling also plays a big role in how satisfied developers are with their team's communication and collaboration. In fact, 36% of developers who sought productivity tools for communications reported they were extremely satisfied with their jobs. In addition to looking at the above metrics to measure the quality of collaboration and communication, we also recommend surveying your team to see if they are satisfied with the tools they use to facilitate it.

Efficiency and flow: Is your team able to work distraction-free?

The final element of the SPACE framework is efficiency and flow. Developers struggle to be productive without the ability to "get in the flow" and work distraction-free. This final element includes tools that help minimize distractions, tools that allow information to flow efficiently, and other processes that promote flow (like agile project management).

Efficiency and flow can be measured and understood by:

  • Amount of uninterrupted working hours a developer has per week
  • Time spent in code and design apps (as opposed to administrative tools)
  • The number of handoffs in a process
  • How easily is information found in a process (e.g., Are devs filling out issues correctly?)
  • Time spent context switching (i.e., How often do I have to switch between two or more tools in a process?)

Productivity management: what it is and how to implement it in a software team

Now that we’ve covered what developer productivity is and what it entails, let's discuss how to manage productivity on software teams.

What is productivity management for software teams?

Productivity management is the process of implementing and tracking tactics meant to enhance a team’s productivity. Tech leaders can use the SPACE framework outlined above to identify areas to enhance and measure the productivity of developers.

To address all elements listed in the SPACE framework, there are many tactics for managing a team’s productivity – from project management to goal setting and tracking, to process automation, to formal retrospectives – all of which can fit under the umbrella of “productivity management.”

At Zenhub, we’ve identified 3 key tactical areas for managing software development productivity:

  • Automated agile processes and project management
  • Measurement and quantification of the team’s productivity/performance
  • Using tools that integrate with each other to reduce context switching

Automated agile processes and project management

Processes and project management contribute largely to the “performance” and “collaboration” part of the SPACE framework as they help teams collaborate efficiently and prioritize tasks by level of impact on the business. In fact, in our survey, developers rated “poor planning” as the #1 obstacle to productivity.4

Agile frameworks and their impact on the productivity of developers

While project management plays a key role in productivity, it can be a productivity drain when it relies on inefficient processes. Because of this, back in 2001, a team of software engineers developed the “agile manifesto,” a project management methodology that focuses on working on only the most impactful work.

Below is a chart of some of the most popular variations of agile project management and the productivity Pros and Cons of each method. It should be noted that most teams do not follow agile frameworks to a tee. Learn about agile realists vs. purists here.

{{guide-table-01}}

Agile process automation and its impact on productivity

The second part of using project management as a way to become more productive is preventing it from becoming a productivity drain itself. Sometimes, agile processes can result in a lot of time-consuming admin work. This is where the tactical approach of automation comes in.

Processes that can be automated in agile are:

Handoffs and workflows

Typically, in agile environments, handoffs are something that we try to reduce or eliminate entirely. Still, for most teams, this is a regular part of collaboration. Minimize the impact this has on efficiency by setting up automation, such as automatically moving issues as their status changes from one team or individual to another. Having an agreed-upon issue template with requirements can also help reduce issues with knowledge transfer.

Sprints

Sprints are a regularly occurring item in an agile environment, so naturally, they can be automated. Consider automating the creation of a new sprint in your team’s regular cadence and automating the movement of issues from one sprint to the next to save your devs time.

Agile estimation

Some aspects of agile estimation can be automated using a digital story point estimation tool like planning poker. For example, you can have planning poker automatically notify team members when an issue needs estimation.

Reporting

A big benefit of agile project management is its emphasis on reporting. However, reporting can be time-consuming if not automated. Automated reporting typically involves either having an agile tool that has reporting built-in, like Zenhub, or integrating your tools with a tool for reporting.



Automated testing

Manual QA work can be monotonous and slow teams down. To combat this, one dev we surveyed said they were using automated testing to improve their team’s efficiency: “More automated testing allows developers to detect problems early in their development cycle, rather than at the end of the sprint when they've handed it off for QA validation.”5
To learn more about agile project management and improving the productivity of agile processes, visit our blog.

Measuring software developer productivity

As the SPACE framework makes it clear, how one measures developer productivity is a debatable and broad subject. There are many factors involved in developer productivity, not all of which are easy to measure. Despite this, most of the developers we surveyed say they engage in some type of productivity measurement.

However, the most common and quantifiable metrics are usually those found in agile methodology. Because of this, we’ll focus mostly on agile metrics in the section below.

Agile reporting metrics for productivity

Velocity

In the simplest terms, velocity calculates the average amount of work completed by a single team during a software development sprint. Velocity is a good metric to track, not only to see how productive a team is in a single sprint but also to estimate productivity using historical data to more accurately estimate release dates.

Tracked using: Velocity chartLearn more about Zenhub velocity charts here.

Throughput

According to our survey, throughput is the most popular method of measuring developer productivity. Throughput measures the total number of units of work (often represented as issues or story points) completed by a team in a given period. As one dev we surveyed puts it, “We measure productivity during sprint planning and retrospectives. Productivity is measured based on story points completed in a given sprint.”6

In agile development, units of work are typically represented by “# of story points,” but you may also choose to calculate it by # of issues or any other terminology that represents a unit of work.

Tracked using: Various reporting tools – cumulative flow charts and burndown charts often display this data or you can also use what some teams call a “throughput histogram.” If your team hasn’t generated any of these reports, you can get instant throughput metrics using our free GitHub analytics tool.

Learn more about tracking throughput using Zenhub here.

Work left in a sprint (“Burndown”)

In agile, “burndown” refers to the amount of work left before the end of a sprint. Calculating burndown allows you to see progress in real-time, identifying possible obstacles to completion.

Tracked using: Burndown chartLearn more about burndown charts in Zenhub here.


Epic and release burndown

Epic and release burndown charts are very similar to the sprint burndown, however, they calculate the burndown for an individual epic or release. These can be useful when measuring progress and identifying blockers in an individual project rather than just in a sprint.

Tracked using: Burndown chart
Learn more about burndown charts in Zenhub here.


Cycle time

Cycle time is the amount of time a team spends working on a product, from planning to release. This includes both time waiting between stages and time working on a product. Cycle time is used for calculating production and can be useful in communicating with stakeholders about how much lead time a team requires to complete a product.

Tracked using: Cycle time scatterplot chart
Learn more about cycle time in Zenhub here.

Time issues spend in each pipeline (cumulative flow)

Tracking “cumulative flow” is just a fancy way of saying that you’re tracking the average number of issues in each pipeline. If you take a look at a cumulative flow chart, the chart used to visualize how much time each issue spends in a pipeline, you may notice some common blockers in your team. This can be really helpful information for project planners to know in order to address frequently occuring bottlenecks.

Tracked using: Cumulative flow chart
Learn more about cumulative flow chart in Zenhub here.

Should productivity be measured at the individual level or the team level?

Why track productivity at the team level: We generally advise tracking productivity at the team level because how a team works together is usually a more accurate indicator of productivity since software development is collaborative. The reporting options for group tracking (i.e. velocity reports, cumulative flow, etc.) are also much more useful for project planning and stakeholder management, whereas individual metrics have few applications beyond performance reviews.

Why track it at the individual level: The main instance in which it's recommended to track individual productivity is if you are an engineering firm that requires individual tracking for billing purposes. In this case, time-tracking software can be used to generate invoices based on billed hours.

Individual developers who want more data points to quantify their contribution to their team for when they're building a portfolio or going into a review may use individual productivity markers

What metrics shouldn’t be used to calculate developer productivity?

Amount of time spent coding: When it comes to time spent coding, quality over quantity is always the best measure of meaningful work. It's difficult to benchmark exactly how much time should be spent coding, and, with team members all at different levels, it would be counterintuitive to measure their effectiveness by “time spent coding.”

The number of lines of code: Once again, quality over quantity. Measuring your developer’s productivity based on “lines of code” is a very quick way to reduce the quality of the code your team produces and lower team morale.

Measuring developer productivity is a nuanced subject. Learn more about measuring developer productivity here.

Tools for improving and managing developer productivity

The final tactical approach for managing developer productivity is implementing the right tools. There are many categories of productivity tools – here are a few most common for development teams:

Productivity measurement tools

Measurement tools track your progress and/or create reports based on your team’s productivity over time and the metrics they are interested in tracking.

Examples:

  • Zenhub’s reporting suite – see how your team progresses on projects, their average velocity per sprint, project bottlenecks, predict release dates, and more.

Time-saving tools

“Time-saving tools” can be anything that saves your team time, regardless of which process/task it's enhancing. Most time-saving tools automate or replace tasks, or simplify processes.

Examples:

  • GitHub co-pilot – Code faster with fewer errors with help from AI automated code suggestions.
  • Rainforest QA – Automate quality assurance testing for faster results with fewer resources.
  • Zenhub's automated sprint planning, automated workflows, and planning poker enable teams to collaborate without the need for regularly scheduled agile meetings.

Project management & collaboration tools

Tools for project management keep teams productive by keeping them aligned on priorities and enabling easy (and usually remote) collaboration so they can work on only the most impactful tasks.

Examples:

  • Zenhub boards and roadmaps – Your Zenhub board is one space to see all of your ongoing tasks and their statuses. Roadmaps allow you to see all projects a team is working on at a high level by date with predicted end dates.
  • Miro – Brainstorm with your whole team on a single virtual whiteboard and allow team members to comment and contribute in real-time.


Get more ideas on tools you can use for developer productivity here.

Conclusion

Developer productivity is so much more than output. It involves people – their skills and well-being; processes – their effectiveness and ability to not "get in the way"; quality assurance – not allowing fast production to hinder performance; and insight – constantly learning from past sprints. Tactically, there is so much that teams can do to manage their productivity, from automating processes to adopting detailed reporting to trying out new tools meant to make everyday tasks more efficient. We hope some of the insights you've learned from this guide can help you manage your team's ongoing productivity optimization. For more productivity tips, visit our blog.

1. November 2022 survey conducted by Zenhub and Wynter.
2. Forsgren, Nicole, et al. “The Space of Developer Productivity.” Queue, vol. 19, no. 1, 2021, pp. 20–48., https://doi.org/10.1145/3454122.3454124.
3. November 2022 survey conducted by Zenhub and Wynter.
4. Ibid
5. Ibid
6. Ibid

{{do-more-cta}}

Do more in GitHub with Zenhub

See all your teams, projects and priorities in one place, with GitHub data providing and up-to-the-minute view into project progress
Contact sales
FrameworkProsCons
Scrum
  • The expected release (almost) always happens every 2 weeks
  • Team is motivated by a fast deadline
  • Easier for developers to understand priorities, the why and the how
  • The project’s segmentation into smaller parts may cause developers to lose sight of the overall vision of the project
Kanban
  • This framework  can easily be adapted to other teams workflows outside of engineering, so can use it org-wide with minimal frustration
  • Lack of timeframes may cause time-related confusion and delays
Extreme programming (XP)
  • Because of its emphasis on simplicity, releases are pushed out faster than ever and improvements and fixes are done rapidly
  • Very transparent processes
  • The speed created momentum and motivation in software teams
  • Because of the team’s speed, it may not be a suitable framework for projects being worked on by people in different time zones
  • There is typically less emphasis on deisgn and XP teams, which could cause user issues

Join the world's most productive software teams

cisco
nikkei
klue
hubspot
zalando
intuit