Cram Sheet312 words
Topic 1.2 — Metrics and queries — cram sheet
Topic 1.2 — Metrics and queries · cram sheet
Flow metrics — the definitions
| Metric | Measures |
|---|---|
| Lead time | Work item creation → completion. Includes the queue |
| Cycle time | Start of active work → completion. Excludes the queue |
| Deployment frequency | How often value ships |
| Time to recovery | Speed of recovery after failure |
| Change failure rate | Share of changes causing failure |
Diagnosis: short cycle time + long lead time = the team is fast but overloaded. Limit WIP; don't just hire.
Planning
- Velocity is a planning input, never a target. Targeted → estimates inflate, prediction dies.
- Widening band on a cumulative flow diagram = a growing queue in that state.
- Query types: flat list · work items and direct links · tree of work items (hierarchy).
Development
- Time to first review is usually the largest hidden delay — larger than build time.
- Misleading: lines of code, commits per developer, individual velocity. All punish helping colleagues.
- High churn = unsettled design in that area.
Testing
- Flaky test rate belongs next to pass rate. 99% pass + 4% flaky ≠ healthy — every failure becomes ambiguous.
- Gate on coverage of changed lines, not repo-wide.
- Coverage shows lines executed, never whether anything was asserted.
Security
- Age of findings beats count. 50 findings under a week ≫ 5 findings two years old.
- Split MTTR by severity — aggregation hides triage failure.
- Dependency currency is a leading indicator of future remediation speed.
Delivery & operations
- Deployment frequency alone is gameable — pair with change failure rate.
- Smaller batches reduce per-deployment risk.
- Alert on user-facing signals; diagnose with infrastructure.
- Report p95/p99, not averages. Azure Monitor logs use KQL.