Team Performance Metrics | Trust-Based Measurement
Measure team performance using outcomes rather than surveillance. GitScrum provides visibility through sprint analytics, cycle time, and quality metrics.
10 min read
Effective performance measurement focuses on outcomes—what the team delivers—rather than activity monitoring. Tracking hours online or commits per day creates surveillance culture that destroys trust and drives away good engineers. Instead, measure what matters: delivery predictability, quality, and sustainable pace.
Outcomes vs. Activity
Why Activity Metrics Fail
MEASUREMENT PHILOSOPHY:
┌─────────────────────────────────────────────────────────────┐
│ UNDERSTANDING WHAT TO MEASURE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ACTIVITY METRICS (AVOID): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ❌ Lines of code written ││
│ │ Problem: More code ≠ better code ││
│ │ Gaming: Write verbose code, avoid refactoring ││
│ │ ││
│ │ ❌ Hours logged ││
│ │ Problem: Presence ≠ productivity ││
│ │ Gaming: Log time without output ││
│ │ ││
│ │ ❌ Commits per day ││
│ │ Problem: Small commits inflated artificially ││
│ │ Gaming: Split work into meaningless commits ││
│ │ ││
│ │ ❌ Tasks closed per day ││
│ │ Problem: Cherry-pick easy tasks ││
│ │ Gaming: Avoid complex, valuable work ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OUTCOME METRICS (USE): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ✅ Sprint goal completion rate ││
│ │ Measures: Team's ability to deliver commitments ││
│ │ Value: Predictability for planning ││
│ │ ││
│ │ ✅ Cycle time (lead time) ││
│ │ Measures: Speed from start to delivery ││
│ │ Value: Identifies bottlenecks in process ││
│ │ ││
│ │ ✅ Escaped defect rate ││
│ │ Measures: Quality of delivered work ││
│ │ Value: Catches quality issues early ││
│ │ ││
│ │ ✅ Customer satisfaction / NPS ││
│ │ Measures: Actual value delivered ││
│ │ Value: Connects work to outcomes ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Team-Level Metrics
What to Track in GitScrum
TEAM METRICS:
┌─────────────────────────────────────────────────────────────┐
│ MEASURING TEAM EFFECTIVENESS │
├─────────────────────────────────────────────────────────────┤
│ │
│ VELOCITY AND PREDICTABILITY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Using GitScrum Sprint Analytics: ││
│ │ ││
│ │ Track over time: ││
│ │ • Points committed vs. points delivered ││
│ │ • Variance between sprints ││
│ │ • Trend: Stabilizing or erratic? ││
│ │ ││
│ │ Sprint 1: Committed 40, Delivered 35 (87%) ││
│ │ Sprint 2: Committed 35, Delivered 38 (109%) ││
│ │ Sprint 3: Committed 38, Delivered 36 (95%) ││
│ │ Sprint 4: Committed 36, Delivered 37 (103%) ││
│ │ ││
│ │ Goal: Consistent 85-100% delivery rate ││
│ │ Red flag: Wild swings (50% one sprint, 120% next) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FLOW EFFICIENCY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Track from board analytics: ││
│ │ ││
│ │ Average cycle time by stage: ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ Backlog │████████████████████│ 14 days │ ││
│ │ │ Ready │███│ 2 days (wait time) │ ││
│ │ │ In Prog │█████│ 3 days (work time) │ ││
│ │ │ Review │████│ 2.5 days (wait time) │ ││
│ │ │ QA │██│ 1 day (work time) │ ││
│ │ │ Done │ Complete │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Work time: 4 days ││
│ │ Wait time: 4.5 days ││
│ │ Flow efficiency: 4 / 8.5 = 47% ││
│ │ ││
│ │ Goal: Reduce wait time, improve flow efficiency ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BLOCKED WORK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Track via labels: ││
│ │ ││
│ │ • Tasks with [blocked] label: count and duration ││
│ │ • Top blocking reasons (analyze comments) ││
│ │ • Time spent blocked vs. working ││
│ │ ││
│ │ High block rate → systemic issue to address ││
│ │ Long block duration → escalation process needed ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Quality Metrics
Measuring Without Micromanaging
QUALITY TRACKING:
┌─────────────────────────────────────────────────────────────┐
│ QUALITY-FOCUSED MEASUREMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESCAPED DEFECTS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Bugs found after release to production ││
│ │ ││
│ │ Track in GitScrum: ││
│ │ • Label: [production-bug] ││
│ │ • Count per sprint / per release ││
│ │ • Severity distribution ││
│ │ ││
│ │ Sprint escaped defect trend: ││
│ │ Sprint 1: 5 bugs (2 critical) ││
│ │ Sprint 2: 4 bugs (1 critical) ││
│ │ Sprint 3: 3 bugs (0 critical) ││
│ │ Sprint 4: 2 bugs (0 critical) ││
│ │ ││
│ │ Trend: Improving ✓ ││
│ │ Note: Team metric, not individual blame ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ REWORK RATE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tasks that come back for additional work ││
│ │ ││
│ │ Track via workflow: ││
│ │ • Tasks moving backward (Done → In Progress) ││
│ │ • Tasks reopened after completion ││
│ │ ││
│ │ High rework rate indicates: ││
│ │ • Unclear requirements ││
│ │ • Rushed development ││
│ │ • Insufficient testing ││
│ │ • Scope creep / moving target ││
│ │ ││
│ │ Address process, not individuals ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TECHNICAL DEBT AWARENESS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Track debt-related work: ││
│ │ ││
│ │ • [tech-debt] labeled tasks: count and trend ││
│ │ • Percentage of sprint dedicated to debt ││
│ │ • Debt paydown vs. accumulation ││
│ │ ││
│ │ Healthy: 15-20% of sprint on maintenance/debt ││
│ │ Red flag: 0% (accumulating) or 50%+ (crisis mode) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Healthy Feedback Practices
Using Data Constructively
FEEDBACK CULTURE:
┌─────────────────────────────────────────────────────────────┐
│ TURNING METRICS INTO IMPROVEMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ RETROSPECTIVE-DRIVEN ANALYSIS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Use metrics in retrospectives—not standups: ││
│ │ ││
│ │ Standup: Focus on today's work ││
│ │ Retro: Analyze patterns and improve ││
│ │ ││
│ │ Retro discussion: ││
│ │ "Our cycle time increased from 3 to 5 days. ││
│ │ What changed? What can we do about it?" ││
│ │ ││
│ │ NOT: ││
│ │ "John only closed 2 tasks this sprint." ││
│ │ → Destructive, creates fear ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TEAM OWNERSHIP OF METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Team chooses what to measure: ││
│ │ ││
│ │ • Discuss which metrics matter ││
│ │ • Set targets together ││
│ │ • Review progress as a team ││
│ │ • Adjust approach based on learning ││
│ │ ││
│ │ Metrics imposed from above → gaming and resentment ││
│ │ Metrics owned by team → genuine improvement ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TREND OVER SNAPSHOT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Always look at trends, not single data points: ││
│ │ ││
│ │ Bad: "This sprint velocity was 32, target was 40" ││
│ │ Good: "Velocity over 6 sprints: 28→32→35→33→36→38" ││
│ │ → Improving trend despite individual variation ││
│ │ ││
│ │ Context matters: ││
│ │ • Holidays in sprint ││
│ │ • Team member sick/on leave ││
│ │ • Major refactoring investment ││
│ │ • Onboarding new team members ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Individual Growth
Supporting Without Surveillance
INDIVIDUAL DEVELOPMENT:
┌─────────────────────────────────────────────────────────────┐
│ GROWING INDIVIDUALS THROUGH TRUST │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1:1 CONVERSATIONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Regular 1:1s focused on: ││
│ │ ││
│ │ • Career goals and growth areas ││
│ │ • Obstacles and how to remove them ││
│ │ • Feedback on team dynamics ││
│ │ • Learning opportunities ││
│ │ ││
│ │ NOT: ││
│ │ • "Why were only 3 tasks completed?" ││
│ │ • "Your hours logged were low" ││
│ │ • "Your commits have decreased" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SELF-REPORTED BLOCKERS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Using GitScrum Team Standup: ││
│ │ ││
│ │ Team members report their own: ││
│ │ • Progress on goals ││
│ │ • Blockers they face ││
│ │ • Help they need ││
│ │ ││
│ │ Manager role: ││
│ │ • Remove blockers ││
│ │ • Connect people who can help ││
│ │ • Provide context and priorities ││
│ │ • Shield team from distractions ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PEER RECOGNITION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Let team members recognize each other: ││
│ │ ││
│ │ In Discussions or retros: ││
│ │ • "Shoutout to Sara for helping debug that issue" ││
│ │ • "Thanks to team for hitting the deadline" ││
│ │ • "Great code review feedback from Alex" ││
│ │ ││
│ │ Peer recognition more meaningful than manager praise ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
What Not to Track
Metrics That Destroy Trust
ANTI-PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ METRICS TO AVOID │
├─────────────────────────────────────────────────────────────┤
│ │
│ SURVEILLANCE METRICS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ❌ Mouse movement / keyboard activity ││
│ │ ❌ Screenshots of screens ││
│ │ ❌ Time spent in specific applications ││
│ │ ❌ "Active" time in Slack/Teams ││
│ │ ││
│ │ Result: People game the system, creativity dies ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ INDIVIDUAL COMPARISONS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ❌ Stack ranking (John > Jane > Bob) ││
│ │ ❌ Individual task counts leaderboards ││
│ │ ❌ Public velocity/points per person ││
│ │ ││
│ │ Result: Competition over collaboration, sandbagging ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PERVERSE INCENTIVES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ❌ Bonus tied to lines of code → bloated code ││
│ │ ❌ Bonus tied to task count → tiny tasks ││
│ │ ❌ Bonus tied to bugs found → writing buggy code ││
│ │ ││
│ │ Result: People optimize for metric, not outcome ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘