Skip to content
Calcrivo

Engineering Productivity Calculator

Calculate a DORA-inspired engineering productivity score from PR throughput, review time, PR size, deployment frequency and on-call load.

Inputs

PRs/week

Number of pull requests merged per week across the team.

hours

Average time from PR opened to first review/approval.

lines

Average lines changed (added + removed) per pull request.

deploys/week

Number of production deployments per week.

interrupts/week

Number of on-call pages/interrupts per week pulling engineers off planned work.

Engineering Productivity Score

91.3

Productivity Tier

Elite

PR Throughput Sub-Score

83.3

Review Time Sub-Score

87.5

PR Size Sub-Score

100.0

Deploy Frequency Sub-Score

100.0

On-Call Load Sub-Score

80.0

Step by step

  1. PR throughput score (25% weight)

    min(100, 25/30×100) × 0.25

    = 20.83

  2. Review time score (20% weight)

    max(0, 100 − 6/48×100) × 0.20

    = 17.50

  3. PR size score (20% weight)

    PR size 180 lines × 0.20

    = 20.00

  4. Deploy frequency score (25% weight)

    min(100, 10/7×100) × 0.25

    = 25.00

  5. On-call load score (10% weight)

    max(0, 100 − 4/20×100) × 0.10

    = 8.00

  6. Overall productivity score

    sum of weighted sub-scores

    = 91.3 (Elite)

How it works

This DORA-inspired composite blends five signals often correlated with healthy, sustainable engineering velocity: PR throughput (25%), PR review turnaround time (20%), PR size (20%, rewarding small reviewable changes), deployment frequency (25%, mirroring DORA's own key metric), and on-call interrupt load (10%, penalizing teams whose planned work is constantly derailed). Each sub-score is normalized 0-100 against common industry reference points before weighting, and the total maps to Elite (85+), High (70+), Medium (50+) or Low (<50).

Formula

productivity_score = pr_throughput_score × 0.25 + review_time_score × 0.20 + pr_size_score × 0.20 + deploy_frequency_score × 0.25 + oncall_load_score × 0.10

pr_throughput_score
min(100, PRs_per_week / 30 × 100)
review_time_score
max(0, 100 - avg_review_hours / 48 × 100)
pr_size_score
100 if ≤200 lines, else max(0, 100 - (lines-200)/800 × 100)
deploy_frequency_score
min(100, deploys_per_week / 7 × 100)
oncall_load_score
max(0, 100 - interrupts_per_week / 20 × 100)

Frequently Asked Questions

Why does smaller PR size score higher?

Research on code review consistently shows smaller PRs get reviewed faster, more thoroughly, and ship with fewer defects than large PRs — this score treats ~200 lines or fewer as ideal and penalizes size growth beyond that as a proxy for reviewability, not raw output.

Isn't more PRs and more deploys always better?

Not unconditionally — this model caps both scores at reference points (30 PRs/week, daily deploys) considered strong-but-sustainable benchmarks, rather than rewarding unbounded throughput that could reflect low-quality, rushed work rather than genuine productivity.

Why penalize on-call interrupts in a 'productivity' score?

Frequent on-call interruptions fragment focus time and divert engineers from planned work, which is a real (if indirect) drag on delivery — including it nudges teams to treat operational load as a first-class productivity concern, not just a reliability one.

Should this replace DORA metrics reporting?

No — treat it as a complementary, easy-to-read team health signal. Formal DORA reporting (deployment frequency, lead time, change failure rate, MTTR) should still be tracked individually for deeper investigation.

You might also need