Code Quality Metrics | Coverage, Complexity & Debt
Track code coverage, cyclomatic complexity, duplication, and tech debt ratio. GitScrum integrates with GitHub, GitLab, and SonarQube for quality-aware planning.
6 min read
Code quality directly impacts development velocity, bug rates, and team morale. Tracking quality metrics helps teams identify problem areas before they become critical. GitScrum integrates with development tools to make quality visible alongside project progress.
Code Quality Dimensions
| Dimension | Metrics | Impact |
|---|---|---|
| Reliability | Bug density, MTTR | User experience |
| Maintainability | Complexity, duplication | Development velocity |
| Security | Vulnerabilities, OWASP | Risk exposure |
| Performance | Load time, efficiency | User satisfaction |
| Testability | Coverage, test quality | Confidence to change |
Key Metrics Framework
Core Metrics
CODE QUALITY METRICS
════════════════════
COVERAGE METRICS:
├── Line coverage: % lines tested
├── Branch coverage: % branches tested
├── Function coverage: % functions tested
└── Target: 70-80% (context-dependent)
COMPLEXITY METRICS:
├── Cyclomatic complexity per function
├── Cognitive complexity
├── Lines per file/function
└── Nesting depth
DUPLICATION METRICS:
├── Duplicated lines %
├── Duplicated blocks
├── Copy-paste detection
└── Target: <5% duplication
TECHNICAL DEBT:
├── Debt ratio (debt/dev time)
├── Debt in hours/days
├── Debt per component
└── Trend over time
Review Metrics
CODE REVIEW METRICS
═══════════════════
SPEED:
├── Time to first review
├── Time to merge
├── Review cycles
└── PR age distribution
QUALITY:
├── Comments per PR
├── Approval rate
├── Rework requests
└── Review depth
PARTICIPATION:
├── Reviews per person
├── Review distribution
├── Reviewer workload
└── Knowledge spread
TARGETS:
├── First review: <4 hours
├── Time to merge: <24 hours
├── Review cycles: <2
└── All team members reviewing
GitScrum Quality Dashboard
Integrated View
QUALITY DASHBOARD LAYOUT
════════════════════════
┌─────────────────────────────────────────────────┐
│ Code Quality Overview │
│ Last updated: 5 min ago │
├─────────────────────────────────────────────────┤
│ │
│ HEALTH SCORE │
│ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░ 78/100 (↑ 3 pts) │
│ │
├────────────┬────────────┬────────────┬──────────┤
│ Coverage │ Complexity │ Duplication│ Debt │
│ 72% ↑ │ 12 ↓ │ 3.2% = │ 4.2d ↓ │
│ Target:70%│ Target:<15│ Target:<5% │ │
└────────────┴────────────┴────────────┴──────────┘
│ │
│ TREND (Last 30 Days) │
│ │
│ Coverage: ────────────────────▲ │
│ Debt: ────────▼────────────── │
│ Bugs: ────────────────────── │
│ │
└─────────────────────────────────────────────────┘
Quality by Component
COMPONENT QUALITY TABLE
═══════════════════════
Component │ Coverage │ Complexity │ Debt │ Status
──────────────────┼──────────┼────────────┼────────┼────────
api/auth │ 85% │ 8 │ 0.5d │ ✓ Good
api/payments │ 72% │ 14 │ 1.2d │ ⚠ Watch
api/users │ 68% │ 11 │ 0.8d │ ✓ Good
frontend/core │ 45% │ 22 │ 2.1d │ ✗ Action
frontend/common │ 78% │ 9 │ 0.4d │ ✓ Good
──────────────────┴──────────┴────────────┴────────┴────────
ATTENTION NEEDED:
├── frontend/core: Low coverage, high complexity
└── api/payments: Complexity trending up
Quality-Aware Planning
Sprint Quality Goals
SPRINT QUALITY GOALS
════════════════════
SPRINT 15 QUALITY TARGETS:
├── Maintain coverage above 70%
├── Reduce api/payments complexity by 2 points
├── Address 3 critical code smells
└── Zero security vulnerabilities
QUALITY TASKS:
├── [TECH] Refactor PaymentProcessor class
│ Estimate: 4h
│ Impact: -3 complexity
│
├── [TECH] Add tests for AuthService
│ Estimate: 6h
│ Impact: +8% coverage
│
└── [TECH] Fix code duplication in validators
Estimate: 2h
Impact: -1.5% duplication
SPRINT CAPACITY ALLOCATION:
├── Features: 70%
├── Bugs: 15%
└── Technical debt: 15%
Quality Gates
QUALITY GATES FOR MERGE
═══════════════════════
AUTOMATED CHECKS:
├── ✓ Coverage ≥ existing coverage
├── ✓ No new critical issues
├── ✓ No new security vulnerabilities
├── ✓ No new code duplication
├── ✓ Complexity within limits
└── ✓ All tests passing
ENFORCEMENT:
├── Block merge if gate fails
├── Require manual override for exceptions
├── Track overrides for review
└── Trend monitoring for regressions
Tool Integrations
SonarQube Integration
SONARQUBE + GITSCRUM
════════════════════
SYNC CONFIGURATION:
├── Project key mapping
├── Webhook for updates
├── Issue sync (optional)
└── Dashboard embedding
VISIBLE METRICS:
├── Quality gate status
├── New code metrics
├── Overall health
└── Issue breakdown
WORKFLOW:
1. Developer pushes code
2. CI runs SonarQube analysis
3. Results sync to GitScrum
4. Quality visible on task
5. Gate blocks if failed
GitHub Integration
GITHUB METRICS SYNC
═══════════════════
PR METRICS:
├── Time to first review
├── Review cycles
├── Comments count
├── Merge time
└── CI status
LINKED DATA:
├── PR linked to GitScrum task
├── Commits visible on task
├── Build status shown
├── Review status synced
└── Auto-close on merge
Quality Improvement Workflow
Debt Reduction Process
TECHNICAL DEBT PROCESS
══════════════════════
IDENTIFY:
├── Regular code analysis
├── Team pain points
├── Hotspot analysis
└── Metric thresholds
PRIORITIZE:
├── Business impact
├── Developer impact
├── Fix effort
└── Risk if ignored
SCHEDULE:
├── 15% sprint allocation
├── Dedicated refactor sprints
├── Boy scout rule (leave better)
└── Never trade velocity for debt
TRACK:
├── Debt items in backlog
├── Trend over time
├── Reduction velocity
└── Celebrate improvements
Best Practices
For Quality Metrics
Anti-Patterns
QUALITY METRIC MISTAKES:
✗ Tracking too many metrics
✗ Focusing only on coverage
✗ Gaming metrics (tests without assertions)
✗ Ignoring quality for features
✗ Blaming individuals for metrics
✗ No action on insights
✗ Metrics without context