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: September 2026
Formula below · 3 sources (bls.gov, pmi.org, Wikipedia) · Updated Sep 2026
Compare with similar
About this calculator
The Productivity Index normalizes task output by the total person-hours the team worked, producing a per-person-per-hour productivity measure. The formula is: Productivity Index = Tasks Completed / (Hours Worked per Person × Team Size). The denominator is total person-hours (for example 8 people × 40 hours = 320 person-hours); dividing tasks by it gives tasks per person-hour. Variables: Tasks Completed is the count of work items the team genuinely finished in the period; Hours Worked per Person is the average hours each member worked in that period; 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 ratio; and the index treats every task as equal, so compare only periods with similar work. For capacity planning, invert it: hours needed = planned tasks ÷ productivity index.
How to use
Example 1 — Customer service team. Tasks completed (tickets resolved) = 240, hours worked = 40 per person, team size = 8. Step 1: total person-hours = 40 × 8 = 320. Step 2: productivity index = 240 / 320 = 0.75 tickets per person-hour. Verify ✓. Trend tracking: if last sprint was 0.69 tickets/person-hour, productivity improved about 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 = 120 per engineer over the 2 weeks, team size = 5. Step 1: total person-hours = 120 × 5 = 600. Step 2: productivity index = 120 / 600 = 0.2 bugs per person-hour, or one bug per 5 person-hours. Verify ✓. A sprint of complex bug fixes might show 0.05 bugs/person-hour — same team, very different 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 0.75 tickets/person-hour, adding 200 tickets/week requires 200/0.75 ≈ 267 additional person-hours/week — about 6.7 full-time people at 40 hours, or more if you keep utilization near a sustainable 75-80%. 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.