Being productive, yes — but compared to what?

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

- Which path should I take?

- Where do you want to go?

- I don’t know.

- Then it doesn’t matter.

To start measuring productivity, we need to compare the team’s performance against some reference, whether quantitative or qualitative. Some examples I often use are:

• Has the sprint goal been achieved?
• Has the PI goal been met?
• Which KPIs were achieved and which ones fell below expectations?

Based on these comparisons, we can understand the team’s actual output in relation to what was expected. This is the first step to identifying whether we are on track, above expectations, or below what is needed. With Saint Jude, this analysis can be done in a consolidated way, comparing projects, teams, and different time periods to show more clearly where productivity is improving and where there are points of attention.

Disclaimer: be careful with excessive pressure to improve metrics that are already healthy. It is better to complete a trip at 100 km/h than to drive at 180 km/h and break the engine halfway through.

With that disclaimer made, I will present some methods I use to measure a team’s productivity:

Measuring your team

Measuring the division of tasks by type: user stories, maintenance, and enablers

This measurement consists of comparing the proportion between the different types of tasks on the board. User stories usually represent functional progress in the product. Maintenance tasks help fix problems or preserve the user experience. Enablers, on the other hand, create the technical foundation needed to scale the product, improve architecture, infrastructure, or internal processes.

When we analyze this balance, we can understand whether the team is truly moving the product forward or spending too much energy fixing problems, resolving technical dependencies, or maintaining something that should already be more stable. Below, I leave an example of how to check this distribution:

Task management on the board and the speed at which tasks are delivered

The point here is to compare deliveries within closed time periods, such as a sprint, PI, month, or quarter. This allows us to understand how much the team usually delivers using the unit of measurement adopted by the team: hours, Fibonacci points, days, or any other reference. With this history, it becomes easier to estimate future deliveries, even though software estimation will always have a certain degree of uncertainty.

A solution like Saint Jude can help precisely with this monitoring by consolidating delivery speed across different boards, projects, and tools. This way, leadership does not depend only on manual reports to understand whether the team is gaining predictability or whether there are significant variations between what was planned and what was delivered.

Time spent – from the moment the task enters until it exits

With this measurement, we can understand how long a task or feature takes from the moment it starts being worked on until its delivery. This analysis becomes even more important when connected to the type of task. For example: maintenance tasks take, on average, 5 days to be completed, while user stories take 3 days.

This type of comparison helps identify where the team is losing time, which types of demands consume more effort, and where there is an opportunity to improve the delivery flow. Below is an example of the relationship between the number of user stories completed and the number of days.

Number of active items

This metric shows how many items are active on the board. I consider it one of the most important measurements for a leader. If you have 5 people on the team and 10 active items, there are probably tasks that are blocked, poorly distributed, or waiting for information to move forward.

In addition, by properly visualizing the board, we can understand which stage of the process each item is in: analysis, development, testing, review, or completion. With Saint Jude, this type of view can be consolidated into dashboards to show excessive WIP, bottlenecks by stage, and possible delay risks before they become a bigger problem.

Efficiency in task execution

In simple terms, this metric helps us understand how much time a task is actually being worked on and how much time it remains stopped between one stage and another in the process. For example: a task may leave development but stay for days waiting for testing. This waiting time reduces flow efficiency and directly impacts delivery predictability.

Below is the calculation used to understand this metric. When the result is close to 1, it means there is little waste of time in the flow.

Flow time = active time – waiting time

Flow efficiency = active time / flow time

How to improve team productivity

Over the years working in project management, I have noticed some patterns that, when corrected, increase delivery speed and improve the product’s time-to-market. Let’s look at them:

System maintenance VS User stories VS Enablers

My view — perhaps a little controversial — is:

• User story means moving forward
• Enabler means moving sideways
• Maintenance means moving backward

Let me explain:

Maintenance tasks often appear when the process was not well defined, when information was missing, or when the previous delivery was not clear enough. This connects to another article I wrote: “Why having a great definition of ready and done is so important for task clarity”. Corrections often arise from a lack of understanding about scenarios, personas, business rules, or acceptance criteria. To solve this, it is necessary to improve processes, communication, and task clarity, even if this seems to take more time at first.

Enablers are very important because they create the technical structure of the product. However, in general, they represent foundations, environments, architecture, integrations, and internal improvements. Depending on the context, part of this work can even be accelerated with external support so that the main team can stay focused on product deliveries.

User stories, on the other hand, are the tasks that generally move the product forward in a visible way for both the customer and the business. The clearer the story is and the faster it is completed with quality, the greater the project’s evolution will be.

How much the team is delivering per time period

Here we enter the comparison between estimate and reality. Personally, I really like planning poker because it not only helps reach an estimate, but also increases clarity about what needs to be done. From there, we can analyze the points, hours, or days delivered in previous sprints, PIs, months, or quarters and use this history as a basis to understand the team’s real capacity.

This is one of the analyses where Saint Jude can generate value for PMOs and leadership, as it allows teams to compare planned versus delivered work, monitor productivity variations, and identify which teams or projects are more predictable over time.

Delivery time for a specific type of task

Here, dividing tasks by type is essential: user story, maintenance, and enabler. We can use the average time of each type of task to better plan a sprint, PI, month, or quarter and estimate how much the project is likely to evolve.

In certain periods, it may make sense to focus more on one type of task. For example: a sprint more focused on reducing maintenance, a PI focused on technical enablers, or a cycle with a greater concentration of user stories to accelerate a strategic delivery.

Waiting time for tasks to move between team members

The goal here is simple: identify which stage of the process tasks are getting stuck in and correct that bottleneck. However, this analysis often leads to an important executive decision:

Do I spend time or money?

Usually, tasks remain stuck because there are not enough people to keep the flow moving. In this case, we are saving money but losing time. By adding more people, the scenario may reverse: we increase cost but reduce waiting time. Even so, if the flow is not well balanced, some professionals may remain idle while waiting for previous stages to be completed. Example: QA waiting for development to finish.

Disclaimer: people are monotask. If you move someone to another activity, that person will only return to the sprint after finishing the new demand, creating more waiting time and loss of focus.

How many active items are there on the board?

When there is no clarity about what needs to be done, many tasks start appearing as active on the board. This happens because a professional picks up a task, does not understand what needs to be done, starts asking other people, and while waiting for an answer, begins another activity.

I return again to the article I wrote: “Why having a great definition of ready and done is so important for task clarity”. The rule should be simple: if you picked up a task and did not understand it, ask the team. If no one can explain it, that task probably should not be in the sprint.

With workload dashboards and active item views, Saint Jude helps visualize this problem in a more executive way, showing when the board has too many open tasks, where work is accumulating, and which projects may be losing productivity due to lack of clarity, focus, or prioritization.

I have reached the end of this article, and I hope it helped you think about productivity in a more structured way. Measuring a team does not mean only demanding more deliveries, but understanding context, flow, capacity, bottlenecks, and the quality of the information that reaches the board.

With the right metrics — and with tools that transform data into visibility, such as Saint Jude — leaders, PMOs, and teams can make better decisions, improve predictability, and increase productivity without depending only on perception or manual reports.

Do you want to continue this conversation? Like the article, comment on LinkedIn, or share it on your social networks.

See you soon!

Erik Scaranello