Team Productivity Index Calculator
Calculate the productivity index as the number of tasks completed per person-hour of work. Use it to compare productivity across sprints, teams, or time periods — accounting for both task volume and team capacity.
Last updated: May 2026
Compare with similar
About this calculator
The Productivity Index normalizes task output by team-hours, producing a per-person-per-hour productivity measure. The formula is: Productivity Index = Tasks Completed / (Hours Worked / Team Size). The denominator (Hours Worked / Team Size) gives average hours per person; dividing tasks by that gives tasks per person-hour. Variables: Tasks Completed is the count of work items the team genuinely finished in the period; Hours Worked is total team-hours (sum across all members); Team Size is headcount. Edge cases: very small team sizes give noisy results (one person's variation swings the average dramatically); large teams may have substantial coordination overhead that doesn't show in the simple formula. The metric is meaningful only when 'task' is consistently sized across measurement periods — comparing one period with 10 large tasks to another with 100 small tasks produces nonsense without size normalization. For tasks of variable size, use story points or completed value (in business terms) rather than raw task counts. The Productivity Index is most useful for: (1) Tracking team productivity trends over time at fixed task definition; (2) Comparing across similar-context teams (same team works on similar work); (3) Resource planning when productivity is roughly stable. It's less useful for: comparing teams with different scope, evaluating individual performance, judging cross-context efficiency. Industries that use task-count productivity productively: customer service (tickets resolved/hour), warehousing (orders picked/hour), manufacturing (units produced/hour), software bug fixing (issues closed/hour). For knowledge work where 'task' size varies wildly, this metric is unreliable.
How to use
Example 1 — Customer service team. Tasks completed (tickets resolved) = 240, hours worked = 320 (8 people × 40 hours), team size = 8. Step 1: hours per person = 320 / 8 = 40. Step 2: productivity index = 240 / 40 = 6 tickets/person-hour. Verify ✓. Trend tracking: if last sprint was 5.5 tickets/person-hour, productivity improved 9% — investigate why (tool improvements, training, easier ticket mix, or process changes). Example 2 — Software bug-fix team. Tasks (bugs closed) = 120 in 2 weeks, hours worked = 600 (5 engineers × 120 hours over 2 weeks but only 60% productive after meetings), team size = 5. Step 1: hours/person = 600 / 5 = 120. Step 2: productivity index = 120 / 120 = 1 bug/person-hour. Verify ✓. 1 bug/person-hour over 120 hours = 1 bug per hour, which is plausible for routine bug fixing with consistent complexity. For comparison: a different sprint with complex bug fixes might show 0.3 bugs/person-hour — same team, very different productivity index because task complexity varies. Compare only sprints with similar work type and task complexity.
Frequently asked questions
How does this differ from velocity (story points/week)?
Both measure team productivity but in different units. Velocity measures story points (a relative-sizing measure) per week. Productivity Index measures tasks per person-hour. Velocity captures effort and complexity via story points; productivity index captures raw task throughput. When story-point estimation is consistent, velocity is more informative because it accounts for task complexity. When tasks are roughly uniform in size (customer service tickets, warehouse orders, repetitive operations), productivity index is simpler and equally informative. For software development, velocity is the standard; for customer service, productivity index works well; for warehouse operations, units/hour is the dominant metric. Pitfalls of both: maximizing either metric incentivizes skipping quality, batching small tasks for high counts, or breaking large work into many small pieces. Always pair throughput metrics with quality measures (defect rate, customer satisfaction, rework rate) to avoid Goodhart's Law gaming.
How do I track productivity trends over time?
Measure productivity index for each sprint or measurement period (weekly, monthly), then plot trend over 8–12 periods. Healthy patterns: stable productivity (consistent performance), gradually improving (continuous process improvement, training paying off), seasonally variable (predictable peaks/valleys with reasons). Concerning patterns: declining trend (burnout, increasing complexity, scope creep), sudden drops (team disruption, system issues), unsustainable spikes (overwork that crashes in following periods). Always pair with quality and engagement measures: rising productivity with falling quality is unsustainable; high productivity with rising turnover is borrowed time. For team-level trending, use trailing 3-period average to smooth noise. For year-over-year comparisons, control for: (1) Team composition changes (new members, departures); (2) Tooling and process improvements (which legitimately improve productivity); (3) Scope changes (different work types affect throughput); (4) External factors (market changes, organizational disruption). Cross-quarter productivity comparisons without these controls are usually meaningless.
What are the most common mistakes with productivity index?
The biggest is treating tasks as uniform when they vary widely in size or complexity; comparing periods with very different task profiles produces meaningless results. The second is using productivity index for individual performance evaluation when team and systemic factors dominate. The third is maximizing the metric without quality controls; teams under pressure to hit productivity targets often skip quality steps that hurt long-term throughput. The fourth is comparing across teams that have very different scope or task types; raw productivity numbers cannot be meaningfully compared between a customer service team and a software development team. The fifth is using productivity index without tracking team engagement or burnout; sustained high productivity often masks deteriorating conditions that lead to mass departures. The sixth is failing to attribute changes to root causes; productivity moves for many reasons (tooling, training, team changes, scope, organizational factors) and any single attribution requires investigation, not just metric tracking.
When should I NOT use productivity index?
Skip productivity index for knowledge work where task size varies widely; use story points (velocity), business value delivered, or outcome metrics instead. Avoid it for creative or research work where output volume doesn't correlate with value (writing 10 mediocre pages isn't better than 1 great page). Do not use it for early-stage projects where 'task' definitions are still emerging. Skip it for team performance evaluation in cultures where individuals already feel surveilled; metrics-based management at the individual level often destroys engagement and creativity in knowledge work. Do not use productivity index alone for cross-team or cross-organization comparisons; the metric is local to a specific context and scale. And do not use it as the sole performance metric for any team — pair with quality, engagement, retention, customer outcomes, and business value for a complete picture. Single-metric optimization always invites gaming and quality loss; balanced scorecards work better for sustainable performance management.
How does this connect to resource utilization and capacity planning?
Productivity index measures output efficiency; utilization measures capacity usage; together they reveal whether more work can be added to a team or if capacity is fully used. Example: a team with 100% utilization and stable productivity index is at full capacity — adding work will hurt productivity (queuing theory: utilization above 80% causes wait time growth). A team with 60% utilization and stable productivity has slack — additional work won't necessarily hurt productivity. Capacity planning uses these together: planned new work / current productivity index = additional person-hours needed; compare to available hours after current utilization. For a team with productivity index 6 tickets/person-hour at 75% utilization, adding 200 tickets/week requires 200/6 = 33 additional person-hours/week, which at current 75% utilization means adding 33/(40×0.25) ≈ 3 person-equivalents of work — likely requiring 4 new hires to maintain quality. Crude estimate but useful for capacity planning. More sophisticated approaches (Little's Law, queuing theory analysis, value-stream mapping) extend these basic metrics for serious operational planning.