PR flow
PR flow measures the path from pull-request creation to completion. Pickup time describes waiting for a first review; review time describes the interval after review begins.
- PR cycle time at p50 and p90.
- Pickup, draft, and review time.
- Long-lived, blocked, abandoned, large, and no-review pull requests.
- Repository and contributor drill-downs.
Deployments and production flow
Deploy time measures the interval from merge to deployment. Lead time to production extends the measurement through release; both require deployment records and links to the delivered work.
- Deployment frequency and success or failure counts.
- Time from merge to deployment.
- Time from pull-request creation to production.
- Pull requests included in each deployment.
Work health from Jira and Linear
Issue histories record what started, what completed, what remains in progress, and what has gone stale. Historical transitions support duration calculations that a current-state snapshot cannot provide.
- Issue cycle time and lead time.
- Throughput and work in progress.
- WIP age and stale issues.
- Epic or project progress and scope movement.
Use metrics as system signals
A metric is useful when it changes a decision. A rising pickup time can justify review capacity; high WIP can justify finishing before starting; a widening p90 can expose inconsistent flow hidden by the median.
Individual detail can support investigation. Context, trends, and distributions are needed to interpret a change in the engineering system.
Choose metrics from the decision backwards
A useful scorecard is small enough to explain and broad enough to expose trade-offs. Start with the decision the team needs to make, then pair an outcome signal with the leading indicators and constraints that can explain it.
| Question | Primary signal | Context and balancing signals |
|---|---|---|
| Where is delivery waiting? | PR cycle time p50 and p90 | Draft, pickup, review, deploy time, PR size |
| Are we shipping reliably? | Deployment frequency and lead time | Deployment outcomes, deploy lag, batch size |
| Is planning flow healthy? | Issue cycle time and throughput | WIP, WIP age, stale work, scope movement |
| Is AI changing delivery? | AI PR and commit rate | Cycle time, review load, PR size, no-review rate |
| Is collaboration concentrated? | Review participation and ownership | Repository context, team topology, work type |
Use a lightweight operating rhythm
Review flow signals weekly with the people who can change the system. Use monthly trends for investment decisions and longer windows for noisy production outcomes. The meeting should end with a hypothesis and an owner, not a larger dashboard.
Keep the scorecard stable long enough to learn, but revisit it when the product, team topology, or delivery model changes. A metric that no longer changes a decision has become reporting overhead.
- Weekly: exceptions, blocked work, pickup and review bottlenecks.
- Monthly: trends, p50 versus p90, work mix, and improvement experiments.
- Quarterly: whether the scorecard still reflects company priorities.
- Always: pair quantitative signals with team context and qualitative feedback.
Frequently asked questions
Which engineering metrics should a software team track?
Start with a small set covering flow, delivery reliability, work health, and the outcome you are trying to improve. PR cycle time, deployment frequency, lead time, throughput, WIP, and one quality constraint are a practical baseline.
What is the difference between engineering metrics and developer productivity metrics?
Engineering metrics describe the delivery system. Developer productivity metrics use several system, experience, and outcome signals to understand whether developers can create value effectively. Neither should be reduced to individual activity counts.
Should metrics be compared across teams?
Only with strong context. Different systems, responsibilities, release models, and work types make raw rankings misleading. Comparisons are most useful for finding questions or sharing practices, not judging individual performance.
How often should engineering metrics be reviewed?
Operational flow can be reviewed weekly, investment and trend questions monthly, and the scorecard itself quarterly. Production reliability metrics may require longer windows when incidents are infrequent.
Sources and further reading
- SPACE: A framework for developer productivityA multidimensional model spanning satisfaction, performance, activity, communication, and flow.
- DORA metrics guidanceDefinitions and guidance for software delivery performance metrics.