
Most advice on how to measure team performance quietly turns into advice on measuring people. Managers add up individual scores, call the total a team score, and wonder why it says so little about whether the team delivered. But a team result is more than its members’ results added up. A project is late or on time as a whole, and the budget overrun shows up only at the project level, never in any one person’s timesheet.
This guide covers measuring team performance with the data a team already produces. We start with how team measures differ from individual ones, then go through six team performance metrics with their formulas and run them on one example with real arithmetic. The later sections deal with the health of the team behind the numbers and with the measures that do more harm than good.
- What is team performance?
- Team performance vs individual performance
- How to measure team performance in 5 steps
- 6 team performance metrics and their formulas
- Worked example: one team, one month
- Measuring how the team works, not only what it delivers
- Software teams: the DORA metrics
- What not to measure
- Tracking team performance in actiTIME
- FAQ
What is team performance?
Team performance is how well a group of people deliver a shared result: the right work, at the agreed quality, by the agreed date, within the agreed budget. Shared is the word to hold on to. Google’s People Analytics researchers, who studied 180 teams in their Project Aristotle research, separated teams from ordinary work groups on exactly this point. In their words, teams “are highly interdependent,” and “team members need one another to get work done” (Google re:Work).
Because of that interdependence, team performance has to be measured on team outputs. If a designer finishes on time but the developer waits two days for an answer from the client, the client still gets the release late. Everyone can pass an individual review while the team misses the date.
Team performance vs individual performance
You need both kinds of measurement, but they answer different questions, so keep them apart. Individual reviews, covered in our guide to the employee performance report, look at one person’s contribution, growth, and behavior. Team measurement looks at what the group delivered together.
| Question | Team measure | Individual measure |
|---|---|---|
| Did we deliver on time? | Share of deliverables shipped by the due date | Whether the person’s own tasks met their deadlines |
| Did we stay on budget? | Project cost against the agreed budget | Rarely meaningful for one person |
| Was the work good? | Rework hours, defects, client acceptance | Peer and manager feedback on the person’s work |
| Can we plan reliably? | Actual hours against estimates across all tasks | Accuracy of the person’s own estimates |
| How do we work together? | Team health survey, handoff delays | Collaboration feedback in the review |
In practice, use team metrics to decide what the team should change and keep them out of individual ratings. Once a team number becomes part of one person’s appraisal, people start protecting their share of it instead of the result.
How to measure team performance in 5 steps
1. Define what the team is supposed to produce
Start from the commitment rather than from whatever data happens to be available. For a client team, that is the contract: deliverables, dates, and budget. For an internal team, it is the goal the team was formed for, such as a product release, a migration, or a service level. If the team cannot say in one sentence what it delivers, no metric will fix that.
2. Cover the four dimensions of performance
The U.S. Office of Personnel Management, which sets performance appraisal rules for federal agencies, groups measures into four general types: quality, quantity, timeliness, and cost effectiveness (OPM, Developing Performance Standards). The list works just as well for a team. A set of metrics that covers only speed will reward cutting corners, and a set that covers only quality will reward missing deadlines. Pick at least one measure for each dimension.
3. Set a baseline before setting targets
Calculate each metric for the last three months before deciding what good looks like. A team that has delivered 70% of milestones on time will not jump to 95% because a target says so, and an unrealistic target only teaches people to game the measure. OPM says much the same about timeliness standards and warns that the most common error “is to allow no margin for error.”
4. Review on a fixed rhythm
Different metrics move at different speeds. Delivery and hours are worth a short weekly look, cost and estimate accuracy a monthly review, and team health a quarterly survey. Reviewing everything every week creates noise and makes normal variation look like a trend.
5. Act on trends, then measure again
One bad month is a data point. Three months moving the same way is a pattern worth a change, such as smaller tasks, an earlier client review, or a different handoff. After the change, keep the same metric and the same formula, so you can see whether it worked.
6 team performance metrics and their formulas
The six metrics below cover all four OPM dimensions and can be calculated from data most teams already record: task lists, due dates, estimates, and timesheets. For a broader list aimed at project managers, see our guide to project management KPIs.
1. On time delivery rate (timeliness)
It is the one measure a client sees directly. Count deliverables, not tasks, because a team can close 40 small tasks and still miss the one release the client was waiting for.
2. Estimate accuracy (timeliness and cost)
100% means the team’s estimates held. A result that stays well above 100% month after month means the team plans too optimistically, and its deadlines will keep slipping until the estimates change. Our article on the planning fallacy explains why this happens even to experienced teams.
3. Throughput (quantity)
Throughput only means something against the team’s own history, because deliverables differ in size from team to team. Compare this quarter with the last one, not one team with another.
4. Rework rate (quality)
Rework is any work done again because the first version was wrong or unclear: fixes after a client review, redone designs, corrected reports. To measure it, the team needs a way to label it, such as a separate type of work or task category for rework. A rising rework rate often points to unclear requirements or late feedback rather than to weak people, and it is frequently the hidden cost behind scope creep.
5. Utilization (cost effectiveness)
For client teams, project work usually means billable work. For internal teams, it means hours on the team’s actual goal as opposed to meetings, admin, and support for other teams. Higher is not always better: a team running near 100% has no room for the unexpected. Our guide to resource utilization metrics covers how to set a sensible range.
6. Budget variance (cost effectiveness)
A positive number means the team spent more than planned. For a team paid by the hour, actual cost is the sum of hours multiplied by each person’s cost rate, so this metric moves together with estimate accuracy and rework rate. When all three rise at once, the cause is usually upstream of the team.
Worked example: one team, one month
The figures below are illustrative. A five person client services team works a four week month, 40 hours a week per person.
Actual cost here is 760 hours at an average cost rate of $54 an hour. Taken together, the numbers say something more specific than any one of them does alone. Effort was not the problem, since utilization is in a normal range. The three late deliverables, the 72 hours over estimate, and the 8% budget overrun all point the same way, and the 61 hours of rework explain most of the gap.
A quick sensitivity check confirms it. If the team cut rework by half, about 30 hours, actual hours on completed tasks would fall to about 522, and estimate accuracy would improve from 115% to about 109%. So the cheapest fix is an earlier client review or a clearer brief rather than more hours or more people. A score per person would never have shown this, because the rework was spread across all five people.
Measuring how the team works, not only what it delivers
Delivery metrics describe the result but say nothing about whether the team can repeat it. Google’s researchers ran into this problem when they tried to measure effectiveness with objective numbers alone. They looked at lines of code, bugs fixed, and customer satisfaction, and concluded that “every suggested measure could be inherently flawed,” since more lines of code are not necessarily better and more bugs fixed means more bugs were created in the first place (Google re:Work).
Their solution was to combine four views: an executive evaluation of the team, the team leader’s evaluation, the team members’ evaluation, and sales performance against quarterly quota. Each group judged a different thing. Executives focused on results, team members on team culture, and team leads on ownership, vision, and goals. The research also found that what mattered most was “less about who is on the team, and more about how the team worked together.”
Project Aristotle named five dynamics of effective teams, and they make a good basis for a short quarterly survey. Ask team members to rate each statement from 1 to 5, anonymously:
- Psychological safety: I can admit a mistake or ask a basic question on this team without being embarrassed.
- Dependability: When teammates say they will finish something, they finish it on time and well.
- Structure and clarity: I know what is expected of me and what the team’s goals are.
- Meaning: The work I do on this team matters to me.
- Impact: I can see how our work affects the client or the company.
Track the average per statement over time rather than one overall score, so you can see which of the five is changing and talk about that one with the team.
Software teams: the DORA metrics
Software teams have a well researched set of team metrics of their own. DORA, a long running research program on software delivery, measures throughput with change lead time, deployment frequency, and failed deployment recovery time, and instability with change fail rate and deployment rework rate (DORA).
DORA is also blunt about comparisons. The metrics are meant to be applied to one application or service at a time, blending them across teams “can be problematic,” and the stated purpose is to improve a team’s performance over time, “not to compete against other teams or organizations.” That advice applies to any team metric. For more on engineering teams specifically, see our guide to developer performance metrics.
What not to measure
Some measures look precise and still make teams worse. Avoid these, or at least handle them with care.
-
Activity instead of output
Keystrokes, mouse movement, screenshots, and active time ratios show that a laptop was busy, not that the work moved forward. Teams measured this way learn to look busy. Measure delivered work, hours on tasks, and estimates instead.
-
Team numbers split into personal scores
Dividing a team’s on time rate among its members punishes the person who stopped to help a colleague. If you need individual input, use a separate review, not a share of the team metric.
-
Rankings between different teams
A support team and a product team do different work and have different normal ranges. Compare each team with its own baseline.
-
Too many metrics at once
A dashboard with 20 numbers is hard to act on. Five or six metrics that cover the four dimensions, plus a quarterly health check, are enough for most teams.
-
Targets that become the goal
Once a number is tied to a bonus, people optimize the number. A team rewarded for on time delivery alone will negotiate looser deadlines. Keep metrics paired, such as on time delivery with rework rate, so that improving one at the expense of the other is visible.
Tracking team performance in actiTIME
Every metric in this guide comes from three kinds of data: tasks with deadlines and estimates, hours logged against those tasks, and cost rates. actiTIME keeps all three in one place, so the calculations come from reports rather than spreadsheets:
- Estimated vs. Actual Time Report shows the variance between estimated and tracked time, which is the estimate accuracy metric.
- Time-Track Report groups work time by project, customer, user, or type of work, so a separate type of work for rework gives you the rework rate.
- Cost of Work Report calculates staff costs from each person’s cost rate, which feeds budget variance. See the Cost of Work Report page for details.
- Budgets can be set on a customer, project, or task, with a progress bar that turns red when the budget is exceeded.
- Deadlines and workflow statuses on tasks give you the inputs for on time delivery and throughput.
For the individual side of the picture, the Staff Performance Report breaks down each employee’s time logs, which keeps individual review data separate from team metrics.
We can generate any report we need
One of the greatest features actiTIME offers is the customizable reporting. We can generate virtually any report we need, grouped in different ways and only for the people assigned to each project. And if the report is not there, well, it’s really easy to create a new one and save it for future use. Go for actiTIME! It’s simple, but also very powerful! You won’t regret the decision. The software + support combination makes actiTIME the best tracking solution in the market.
FAQ
What are 5 examples of metrics to measure performance?
For a team, five solid examples are on time delivery rate, estimate accuracy, rework rate, utilization, and budget variance. Together they cover the four dimensions OPM uses for performance standards: quality, quantity, timeliness, and cost effectiveness.
What are the 5 C’s of high performing teams?
There is no single official list. Different consultants and authors use different sets of C words. A research based set of five team factors comes from Google’s Project Aristotle: psychological safety, dependability, structure and clarity, meaning, and impact.
What KPIs should a team leader track?
A team leader is accountable for the team’s result, so the leader’s KPIs are the team’s KPIs: on time delivery, estimate accuracy, budget variance, and rework rate, plus the trend in the team health survey, which shows how the team works and not only what it delivered.
How often should you measure team performance?
Look at delivery and hours weekly, review cost and estimate accuracy monthly, and run a team health survey quarterly. Judge changes on three months of data, not one.
How do you evaluate team performance fairly?
Compare the team with its own baseline rather than with other teams, combine delivery metrics with the team’s own view of how it works, and agree on the formulas before the period starts. Keep team metrics out of individual ratings so that people are not penalized for helping each other.
Measure the team as a team
Measuring team performance works when the measures match what the team delivers together: on time delivery, estimate accuracy, throughput, rework, utilization, and budget. Add a short health survey to see how the team works, compare each team only with itself, and read the metrics together, the way the worked example does. For most teams, that is enough to find the one change worth making.
To get these numbers from your team’s real hours and tasks, start a free trial of actiTIME. It runs for 30 days with every feature included, and afterward you can keep the permanent free version for teams of up to 3 users.




