TempoPR flow
Tempo measures the path from pull-request creation to completion and separates the stages that teams can act on. Pickup time shows how long work waits for a first review; review time shows what happens 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
Merge speed is only part of delivery. Tempo links deployments to pull requests to calculate deploy time and lead time to production when deployment data is available.
- 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 data adds the planning side of the system: what started, what completed, what remains in progress, and what has gone stale. Tempo uses status histories rather than a single current-state snapshot.
- 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.
Tempo keeps individual detail available for investigation, but the primary unit of improvement is the engineering system. Context, trends, and distributions matter more than a single number.
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.