What are productivity metrics?

Productivity metrics are measurements used to compare the results produced by a team with the time, capacity, and resources available to produce them.

For a software development team, that can mean answering questions such as:

• How much work does the team complete per sprint or month?
• How long does a task take from start to completion?
• How many items are being worked on at the same time?
• How much time is spent actively working?
• How much time is spent waiting between stages?
• How close is planned work to delivered work?
• Is the team becoming more or less predictable over time?

There is no single productivity KPI that can answer all of these questions.

That is why I prefer to look at productivity as a combination of signals rather than trying to reduce developer performance to a single number.

Developer productivity: compared to what?

My first point begins with a conversation from Lewis Carroll’s Alice in Wonderland:

- Which path should I take?

- Where do you want to go?

- I don’t know.

- Then it doesn’t matter.

The same logic applies to productivity.

Before choosing a metric, you need a reference. Otherwise, saying that a team is “productive” or “not productive” does not mean very much.

Some of the references I usually consider are:

• Was the sprint goal achieved?
• Was the PI objective delivered?
• How close was planned work to completed work?
• Which productivity KPIs were achieved?
• Which indicators fell below expectations?
• Is delivery capacity increasing, decreasing, or remaining stable?

These comparisons help us understand actual team output in relation to what was expected.

That is the first step toward understanding whether the team is on track, exceeding expectations, or delivering below the capacity required by the project.

With Saint Jude, this type of analysis can be consolidated across projects, teams, and different periods. Instead of looking at one isolated board, leadership can identify where productivity is improving, where predictability is falling, and which projects require attention.

One important warning: be careful about putting pressure on teams simply because you have found a metric that can be increased.

It is better to finish a journey at 100 km/h than to drive at 180 km/h and destroy the engine halfway through.

A productivity metric should help a team work better. It should not automatically become a reason to demand more output.

Which productivity metrics should software teams track?

There are dozens of employee productivity metrics and engineering KPIs available. For software development teams, however, I find a smaller group especially useful because they can be derived directly from the delivery workflow.

These include:

• Work distribution by task type;
• Throughput;
• Delivery velocity;
• Cycle time;
• Work in Progress - WIP;
• Waiting time;
• Flow efficiency;
• Planned versus delivered work.

1. Work distribution by task type

One of the first productivity metrics I look at is how the team’s capacity is being distributed.

In a software project, work can often be divided into categories such as:

• User stories;
• Maintenance and bug fixes;
• Technical enablers.

User stories usually represent functional progress in the product. Maintenance work fixes problems or preserves the existing user experience. Enablers create the technical foundation required for architecture, infrastructure, integrations, security, or future scalability.

Looking at this distribution helps us understand where development capacity is actually being consumed.

A team can look extremely busy while making very little visible progress because much of its capacity is being spent fixing issues, handling technical debt, or maintaining unstable systems.

This is why simply counting completed tasks is a poor developer productivity metric.

2. Throughput and delivery velocity

Another useful productivity metric is how much work the team completes within comparable periods such as a sprint, PI, month, or quarter.

Depending on the team, that could be measured using completed items, story points, hours, or another consistent unit.

The important question is:

What is this team’s actual delivery capacity?

Once you have several periods of historical data, patterns begin to appear and forecasts become easier to build.

One important caveat: I would avoid comparing story points or velocity directly across different teams. Teams estimate work differently, and a story point does not necessarily mean the same thing from one team to another.

The more useful comparison is usually the evolution of the same team over time.

Saint Jude can support this analysis by consolidating delivery data across boards and projects, helping leadership see variations between planned and delivered work and understand whether delivery capacity and predictability are improving.

3. Cycle time: how long does work take to complete?

Cycle time measures how long an item takes from the moment work begins until it is completed.

It is one of the most useful developer productivity metrics because it shows the real speed of the delivery flow.

The metric becomes even more useful when tasks are separated by type.

For example:

• Maintenance tasks take an average of 5 days;
• User stories take 3 days;
• Technical enablers take 8 days.

This makes it easier to understand which kinds of work consume more time and which ones have the greatest impact on delivery schedules.

It can also reveal that an item is not slow because the work itself is difficult, but because it spends several days waiting between stages.

4. WIP: how much work is active at the same time?

WIP stands for Work in Progress and represents how many items are being worked on simultaneously.

I consider it one of the most important productivity metrics for any project or engineering leader.

If you have five people on a team and ten, fifteen, or twenty items marked as active, there is a good chance that some of them are blocked, poorly distributed, waiting for information, or simply not moving.

More work started does not necessarily mean more productivity.

Quite often, it means the opposite: more context switching, less focus, and longer completion times.

It is also important to understand where WIP is accumulating:

• Analysis;
• Development;
• Code review;
• Testing;
• Validation;
• Completion.

Saint Jude can consolidate this information into dashboards that highlight excessive WIP, bottlenecks by stage, and potential delay risks before they become visible in executive schedules.

5. Flow efficiency: how much time is work and how much is waiting?

A task can take ten days to reach completion without anyone actively working on it for ten days.

For example, it might spend:

• 2 days in development;
• 3 days waiting for code review;
• 1 day being corrected;
• 4 days waiting for testing.

In that scenario, most of the delivery time was not productive work. It was waiting.

Flow efficiency helps separate active time from total flow time.

Total flow time = active time + waiting time

Flow efficiency = active time / total flow time × 100

The higher the percentage of active time, the more efficient the flow tends to be. Low flow efficiency often indicates queues, dependencies, blockers, or bottlenecks between stages.

This is also a good example of why developer productivity should not be reduced to measuring individual developers.

Very often, the problem is in the system around them.

How to improve developer and team productivity

Measurement only matters if it helps us make better decisions.

Over the years working in project and program management, I have noticed several patterns that, when corrected, can improve delivery speed, predictability, and time-to-market.

Understand how much capacity becomes product, maintenance, or enablers

My view — perhaps a little controversial — is:

• A user story means moving forward;
• An enabler means preparing the road ahead;
• Maintenance means recovering lost ground.

That does not mean maintenance or enablers are bad. Both are necessary.

The problem starts when they consume an excessive amount of the team’s available capacity.

Maintenance tasks can sometimes appear because the process was not clearly defined, information was missing, or the previous delivery lacked enough clarity.

This connects directly to another article I wrote: “Why a strong Definition of Ready and Definition of Done brings clarity to your task”.

Rework can result from incomplete scenarios, unclear personas, missing business rules, dependencies, or weak acceptance criteria.

Spending a little more time creating clarity before development may feel slower at first, but it can save days of rework later.

Enablers are also important because they create the technical foundation required for the product to continue evolving: architecture, infrastructure, security, environments, integrations, and internal improvements.

The goal is to understand what percentage of capacity is being consumed by each type of work and whether that distribution matches the project’s priorities.

Compare planned work with delivered work

One of the best productivity KPIs is not simply how much was delivered, but how much of what was planned was actually delivered.

I personally like planning poker because it does more than produce an estimate. The discussion required to reach that estimate often creates more clarity about what needs to be built.

From there, we can analyze story points, hours, completed tasks, or days across previous sprints, PIs, months, or quarters to understand the team’s actual capacity.

A team that plans 100 and consistently delivers 95 may be healthier and more predictable than a team that plans 150, delivers 70 in one cycle, and 140 in the next.

For PMOs and engineering leadership, this is one of the areas where Saint Jude can add significant value by comparing planned versus delivered work, monitoring variations over time, and identifying which projects are becoming more or less predictable.

Measure cycle time by type of work

Not all tasks are the same.

User stories, maintenance, and technical enablers have different characteristics. Comparing cycle time across these categories helps improve estimates and identify specific delivery problems.

In some periods, it may also make sense to intentionally change the distribution of work.

For example:

• A sprint focused on reducing maintenance;
• A PI focused heavily on technical enablers;
• A delivery cycle with more user stories to accelerate a strategic product release.

Reduce waiting time between stages

If a task spends two days in development and five days waiting for testing, your main productivity problem may not be development.

It may be the queue.

That is why waiting time can be just as important as execution time.

This type of analysis often leads to a simple executive decision:

Do I spend time or money?

Tasks often remain blocked because one stage of the workflow does not have enough capacity to keep up with the rest.

If there are many developers and too few QA professionals, for example, a growing queue of work may begin waiting for testing.

Adding capacity costs money. Not adding capacity costs time.

The goal of the productivity metric is to make that trade-off visible so leadership can make a deliberate decision.

Another important point is context switching. People do not effectively perform five complex tasks at the same time. Every time someone abandons one activity to respond to another priority, the original work loses focus and usually takes longer to finish.

Control how many items are active on the board

When work is unclear, the number of active tasks often begins to grow.

A developer picks up a task, finds missing information, asks someone for clarification, and waits for an answer. While waiting, another task is started.

Then another dependency appears, and a third task begins.

Soon, there are many tasks “in progress,” but very few actually moving toward completion.

This is another reason I often refer back to: “Why a strong Definition of Ready and Definition of Done brings clarity to your task”.

My rule is simple: if someone picks up a task and cannot understand what needs to be delivered, ask the team. If no one can explain it clearly, the task may not be ready to enter the sprint.

With workload, WIP, and active-item dashboards, Saint Jude helps turn this operational problem into a management view: where work is accumulating, which projects are losing flow, and where clarity, focus, or capacity may be missing.

What are the most useful developer productivity metrics?

If I had to summarize the productivity metrics I find most useful for software development teams, I would start with these:

• Planned vs. delivered: measures team predictability;
• Throughput: measures how many items are completed during a period;
• Cycle time: measures how long work takes from start to completion;
• WIP: measures how many items are being worked on simultaneously;
• Waiting time: shows how much of the delivery flow is idle;
• Flow efficiency: compares active work time with total flow time;
• Work distribution: shows where team capacity is being consumed;
• Capacity variation over time: helps show whether team productivity is improving or declining.

None of these metrics should be analyzed in isolation.

A team can increase throughput while also increasing rework. It can reduce cycle time simply by choosing smaller tasks. It can increase velocity by changing how it estimates work.

This is why software team productivity needs to be understood as a system of signals rather than a single score.

Should you measure individual developer productivity?

This is where developer productivity metrics can become dangerous.

It is tempting to rank developers by number of tasks, story points, pull requests, commits, or other individual outputs.

But software delivery is a team activity surrounded by dependencies, reviews, architecture decisions, testing, unclear requirements, blockers, and shared responsibilities.

A developer may appear “slow” because the work is unclear, because the testing queue is overloaded, or because the task depends on another team.

That is why I prefer to measure the delivery system first.

Before asking:

“Why did this developer deliver less?”

I would ask:

• Why did the work remain blocked?
• How much WIP is in the system?
• Where is the bottleneck?
• How much waiting time exists?
• How much capacity is consumed by rework?
• Is the team planning more than it can realistically deliver?

How Saint Jude helps measure software team productivity

Most companies already have the data required to calculate these productivity metrics.

The data is distributed across Jira, Azure DevOps, ClickUp, Monday.com, Asana, and other tools used by delivery teams.

The real challenge is turning hundreds or thousands of tasks into useful information for the people who need to make decisions.

Saint Jude works as an intelligence layer on top of this project data, helping managers, PMOs, and engineering leaders monitor:

• Team productivity and capacity;
• Planned versus delivered work;
• Throughput and delivery speed;
• Cycle time;
• WIP and active work;
• Bottlenecks and blocked tasks;
• Delay risks;
• Costs and resource consumption;
• Project predictability.

The goal is not to use data to monitor people.

The goal is to give leaders enough visibility to understand where a project is losing productivity, time, and margin before those problems become visible in the final result.

Measure the system before measuring the developer

I will finish this article with the idea I consider more important than any productivity formula.

Measuring productivity should not mean constantly asking:

“Why didn’t this developer deliver more?”

There are usually better questions:

• Why was this task blocked?
• Why do we have so much work in progress?
• Where is the bottleneck?
• Why are we planning more than we can deliver?
• How much capacity is being consumed by maintenance?
• Where are we generating rework?

That is where productivity metrics really become useful.

With the right metrics — and tools that transform project data into visibility, such as Saint Jude — leaders, PMOs, engineering managers, and development teams can make better decisions, improve predictability, and increase productivity without relying only on perception or manual reporting.

If your team works remotely or in a hybrid model, I also wrote about this specific challenge in: “How to track remote team productivity without micromanagement”.

Want to continue the conversation? Like the article, leave a comment on LinkedIn, or share it with someone who is also trying to better understand software team productivity.

See you soon!

Erik Scaranello