Essential Agile Metrics for R&D Teams: Boost Delivery & Quality
This article presents a comprehensive set of agile and R&D process metrics—including delivery cycle, team productivity, sprint throughput, integration frequency, technical debt, and test coverage—detailing their definitions, calculation formulas, recommended improvement actions, and normal versus warning ranges to help engineering teams monitor and enhance performance.
Agile Key Metrics
Demand Delivery Cycle
The metric reflects the average delivery efficiency of an agile team, measured from story creation to TPM acceptance.
Calculation: avg(TPM accepted time - user story creation time) (excluding weekends and holidays)
Improvement suggestions:
Timely clean up invalid user stories in Jira.
Prepare next sprint stories before the planning meeting.
TPM promptly accepts tested stories.
Reduce waiting time in the process.
Introduce engineering practices such as automated testing and CI/CD.
Reference range: 5‑25 days
Team Productivity
Indicates the average daily delivery capability per person; stable for mature teams.
Calculation: Sprint throughput / (story and sub‑task assignees × working days in sprint)
Improvement suggestions:
Use a unified absolute estimation baseline (1 story point = 1 person‑day).
TPM clarifies user stories during sprint planning.
Update story status promptly during the sprint.
Reference range: 0.70‑1.00
Warning range: ≤0.5 or ≥1.25
Unplanned Stories
Shows the proportion of new demand added within a sprint; healthy if below 10%.
Calculation: Story points of new stories added during sprint / total story points at sprint start
Improvement suggestions:
TPM should pre‑plan 1‑2 stories before sprint start and align with business.
Avoid adding new stories after sprint begins.
For high‑priority requests, obtain product and business approval and negotiate swaps with existing stories.
Reference historical sprint throughput for planning.
Reference range: ≤10%
Warning range: ≥25%
Sprint Story Completion Rate
Measures the achievement of sprint commitments under normal conditions.
Calculation: Sum of story points completed in sprint / total story points at sprint start
Improvement suggestions:
Daily check sprint progress and risks; adjust using sub‑task due dates or latest test dates.
Analyze reasons for < 100% completion in retrospectives and improve next sprint.
Ensure clear understanding of stories and accurate sizing during planning.
Plan sprint based on historical capacity.
Minimize unplanned stories.
Reference range: 90%‑110%
Warning range: ≤75% or ≥125%
Sprint Throughput
Overall capacity of the agile team; should be stable for mature, stable teams.
Calculation: Sum of story points completed in the sprint
Improvement suggestions:
Standardize estimation baseline during sprint planning.
TPM clarifies stories for accurate estimation.
Update completed story status promptly.
Base total story points on team size, historical capacity, and sprint length.
Reference range: 0.70 × people × days – 1.00 × people × days
Demand Backlog
Reflects the amount of stories awaiting scheduling; reasonable if not exceeding two sprints.
Calculation: sum(unfinished story count) × 3 (average story size = 3 person‑days)
Improvement suggestions:
Timely clean up invalid stories in Jira.
Enter next sprint stories before planning.
Regularly groom the backlog.
Reference range: 1‑2 × historical average throughput
Task Completion Rate
Shows the planning completion at the sub‑task level.
Calculation: (sub‑tasks completed before sprint end) / (all sprint sub‑tasks) × 100%
Improvement suggestions:
Break tasks into finer granularity.
Mark sub‑tasks as “Done” promptly after completion.
Plan work ahead when splitting tasks.
Use a Jira dashboard to track due sub‑tasks and update status in real time.
R&D Process Metrics
Integration Count
Number of continuous integration executions for ALM sub‑projects in DevOps.
Calculation: Sum of pipeline integration counts within the last 14 days (both automatic and manual).
Integration Success Rate
Success rate of continuous integrations for ALM sub‑projects.
Calculation: Sum of successful pipeline integrations / sum of total pipeline integrations (last 14 days).
Reference range: ≥50%
Technical Debt
Cost of fixing code quality issues.
Calculation: Sum of pipeline technical debt from static code scans of all master branches.
Reference range: ≤20 person‑days
Technical Debt Density
Ratio of technical debt to lines of code.
Calculation: Sum of technical debt / sum of pipeline code lines (static scans).
Reference range: ≤0.5
Unit Test Coverage (Overall)
Proportion of source code exercised by unit tests during CI.
Calculation: sum(test coverage × code lines) / sum(code lines) from all pipelines.
Reference range: ≥25%
Unit Test Coverage (Frontend)
Same metric for H5 pipelines.
Reference range: ≥25%
Unit Test Coverage (Backend)
Same metric for SpringBoot/Tomcat pipelines.
Reference range: ≥25%
Unit Test Case Count
Total number of unit test cases in CI.
Calculation: Sum of test case counts from all pipelines.
Unit Test Execution Count
Number of times unit tests are executed in CI (last 14 days).
Calculation: Sum of test execution counts from pipelines.
Test Metrics
Smoke Test Execution Count (Last 2 Weeks)
Total number of smoke test cases executed in the past two weeks.
Calculation: Jira smoke test executions + DevOps smoke test executions.
Smoke Test Overall Pass Rate (Last 2 Weeks)
Pass rate of smoke tests across Jira and DevOps.
Calculation: (Passed Jira smoke tests + Passed DevOps smoke tests) / (Total Jira smoke tests + Total DevOps smoke tests).
Automation Test Ratio
Proportion of automated test cases in the quality platform to total automated test cases.
Calculation: Automated test cases executed by quality platform / total project test cases in JIRA.
Incremental Test Coverage
Coverage of new code by the most recent completed test plan.
Calculation: Covered lines of code / new lines of code × 100%.
Full‑Scope Test Coverage
Coverage reported by the most recent completed test plan.
New Defect Count (Last 2 Weeks)
Total number of new defects created in the past two weeks (offline + production).
Mid‑Level and Above Defect Ratio
Proportion of defects of medium severity or higher.
Calculation: Mid‑level effective defect count / total effective defect count (defects created in last 14 days).
Reference range: 60%‑80%
Software Development Quality
Discussions on software development quality, R&D efficiency, high availability, technical quality, quality systems, assurance, architecture design, tool platforms, test development, continuous delivery, continuous testing, etc. Contact me with any article questions.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
