Agile · Measurement & delivery systems

Agile KPIs and Tools for Project Management

Agile measurement connects how work flows, how reliably it is delivered, and whether it produces business value. A faster team is not necessarily a more valuable team—and a dashboard is only as credible as its definitions and source data.

An in-depth guide for project managers, product owners and delivery teams. Examples and numerical targets below are illustrative, not industry benchmarks.

Abstract kanban board with cards arranged in columns

Choose indicators that lead to decisions

A metric is a measurement. A KPI is a measurement deliberately selected to judge progress toward an important objective. Do not make every field in a tool a KPI. Start with the business problem, identify the delivery constraint, then choose a small balanced set that tells you whether your intervention works.

Select Agile measures based on the question and framework
Question	Useful measures	When to use them
Are requests reaching users sooner?	Lead time, cycle time, upper percentiles, ageing work and WIP.	Kanban or any flow-based service; also useful inside Scrum to reveal waiting and blockers.
Are sprints delivering the intended outcome?	Sprint Goal achievement, completed work and scope change; same-team velocity for planning.	Scrum teams with meaningful goals and a stable Definition of Done.
Can we release safely and recover?	DORA metrics, escaped defects, incident severity and service reliability.	Software teams using XP/continuous delivery or other engineering practices; not a generic measure of every business project.
Is the investment producing value?	Adoption, task success, satisfaction and the agreed business outcome.	Every framework, including Lean, scaled Agile and hybrid delivery.

For a new dashboard, start with one outcome measure, one speed measure, one live congestion signal and one quality guardrail. For example: booking task success, request-to-delivery lead time, oldest active item age and severe production defects. Add measures only when they support a named decision.

Improve the system, not the score

Never use velocity, ticket count or commits to rank individuals. Rewards attached to easy-to-inflate numbers encourage splitting tickets, hiding defects and lowering ambition. Discuss trends with the team, understand the context and pair speed with quality, value and sustainable workload.

Agile KPIs: definitions, formulas and how to measure them

Define the population, time window and start/finish boundaries before calculating anything. Keep units consistent, exclude test records transparently, and segment materially different work. A KPI should be reproducible by someone other than the person who built the dashboard.

01 · How long does a started work item take to finish?

Cycle time

Definition & measurement: Finished timestamp − started timestamp, for each completed item. Define the commitment/start point and the Done boundary; include waiting and blocked time inside them. Choose calendar or working days consistently. Report the median and an agreed upper percentile, not only the mean.
Worked example: Five items finish in 2, 3, 4, 6 and 10 calendar days. Median cycle time is 4 days; the long tail shows why promising every item in 4 days is unsafe. For a percentile, document the calculation method and sample size.
Data source: Board transition history: first entry into the defined active state through accepted Done.
Management decision: If the upper tail grows, inspect review queues, handoffs and blockers before asking people to work faster.
Interpretation trap: Do not drop blocked days or unfinished work from the story. Inspect work item age alongside completed-item cycle time; recently completed easy items can hide old stuck work.

02 · How long does the customer wait from request to delivery?

Lead time

Definition & measurement: Delivered timestamp − request timestamp. Specify whether request means intake, approval or commitment. Request-to-delivery lead time usually includes waiting before work starts; it is not automatically the same as cycle time.
Worked example: A request arrives on 1 April, starts on 8 April and is delivered on 13 April at the same time of day: 12 calendar days of lead time, including 7 days before start and 5 days of cycle time.
Data source: Intake record, board history and release/acceptance timestamp joined by a stable item ID.
Management decision: When cycle time is stable but lead time rises, address intake overload, prioritisation and release delays.
Interpretation trap: A board's Done state may precede production availability. Label both dates rather than presenting internal completion as customer delivery.

03 · How much work actually finishes in a fixed interval?

Throughput

Definition & measurement: Count of items crossing the agreed finish boundary per week or sprint. Segment comparable work types and use several periods of history for forecasting.
Worked example: Weekly completions are 8, 10, 7 and 11: 36 items in four weeks, averaging 9 per week. That is historical evidence, not a guaranteed commitment to 9 next week.
Data source: Distinct completed item IDs and completion dates; exclude duplicate Done transitions.
Management decision: Use the observed distribution to discuss likely delivery ranges and capacity constraints.
Interpretation trap: Splitting items into smaller pieces changes the count. Track item-size policy and work mix; do not compare teams using raw ticket counts.

04 · How much work is started but not finished?

Work in progress (WIP)

Definition & measurement: Count all items between the chosen start and finish boundaries at a point in time, including blocked items. Inspect WIP by workflow stage and compare with explicit team limits.
Worked example: Four items are in development, three in review and two blocked: WIP is 9 if all are inside the active boundary. The two blocked items are not removed from the total.
Data source: Daily board snapshots or reconstructed state history.
Management decision: Stop starting and help finish when review queues or ageing work grow. Revisit limits collaboratively rather than silently raising them.
Interpretation trap: A low WIP count is not evidence of value on its own. Hidden spreadsheets, subtasks and off-board work undermine the measure.

05 · Which unfinished items are becoming unlikely to meet the team's forecast?

Work item age and service level expectation

Definition & measurement: Age = current time − started time for every unfinished item. Compare age with a service level expectation (SLE), expressed as a time and probability based on relevant historical cycle times.
Worked example: An illustrative SLE is '85% of standard requests finish within 8 calendar days'. An unfinished request aged 9 days deserves investigation; the 85% statement is a historical expectation, not a universal Agile target or a contractual guarantee.
Data source: Start timestamps, current active items and a documented historical reference period.
Management decision: Review the oldest items daily, identify the next action and assign a blocker-resolution owner.
Interpretation trap: Do not claim high confidence from a tiny or changed sample. Separate expedite items and reassess expectations when the workflow changes.

06 · What amount of estimated work has this Scrum team completed over comparable sprints?

Velocity

Definition & measurement: Sum the team's estimates for items meeting its Definition of Done in a sprint. Use a range across recent comparable sprints; record capacity, scope and estimation changes.
Worked example: A team completes 24, 28 and 20 story points in three sprints: average 24. If the next sprint has less capacity, blindly committing to 24 is not justified.
Data source: Sprint report, estimates at the agreed snapshot and accepted Done status.
Management decision: Support the same team's near-term planning and expose overly optimistic forecasts.
Interpretation trap: Story points are local estimates, not hours, value or individual productivity. Never rank teams, reward point inflation or give partial credit to unfinished work. Velocity is not required by Scrum.

07 · Did the sprint achieve its intended outcome?

Sprint Goal achievement

Definition & measurement: Agree observable success criteria for the Sprint Goal before work begins. At review, record achieved/not achieved and the evidence. Achievement rate = achieved goals ÷ reviewed sprints × 100; document how exceptional or cancelled sprints are handled.
Worked example: Four of five reviewed Sprint Goals are achieved: 80%. Finishing all tickets would still not prove success if the goal was to enable customers to complete a new booking journey and that journey does not work.
Data source: Sprint Goal, acceptance evidence and Sprint Review decision log.
Management decision: Discuss dependencies, interruptions and whether goals are cohesive and achievable.
Interpretation trap: Avoid easy goals chosen to protect the percentage. Inspect the reason and business effect of each missed goal instead of punishing the team.

08 · Is remaining work reducing, or is the scope moving?

Burn-down, burn-up and scope change

Definition & measurement: A burn-down plots remaining work against time; a burn-up plots completed work and total scope. Use one consistent unit. Scope-change rate can be defined as added scope units ÷ baseline scope units × 100, with removals reported separately.
Worked example: A release begins with 100 estimated units and adds 20: gross added scope is 20%. Completing 30 units while scope grows to 120 leaves 90, not 70, remaining.
Data source: Baseline snapshot, dated estimate/scope changes and completion history.
Management decision: Use burn-up to distinguish slow delivery from growth in demand; negotiate scope, date or capacity explicitly.
Interpretation trap: These charts do not prove customer value. Do not hide added work, replace the baseline without a record, or assume a perfectly straight trend.

09 · How much elapsed delivery time is lost to dependencies or impediments?

Blocked time

Definition & measurement: Sum the duration of blocked intervals per item. A locally defined blocked-time share = non-overlapping blocked duration ÷ cycle duration × 100, using the same time unit.
Worked example: An item takes 8 calendar days from start to finish, including 2 days blocked by access approval: blocked-time share is 25%.
Data source: Timestamped blocked flags, reasons and resolution events; a current label alone is insufficient.
Management decision: Group recurring causes, assign organisational owners and remove the largest recurring delay.
Interpretation trap: Do not double-count overlapping blockers or treat every wait as a person's failure. Define whether ordinary review queues count as blocked.

10 · What quality problems reach customers after release?

Escaped defects

Definition & measurement: Count confirmed production defects by severity, release and a fixed observation window. If using a rate, define the denominator—for example affected transactions per total transactions, or production defects per release. A count and a rate answer different questions.
Worked example: A release has 3 confirmed production defects within 30 days, including 1 severe defect. Report severity and exposure; do not claim 3 is better than 5 from a much larger release without context.
Data source: Incident/defect tracker linked to deployment and root-cause records.
Management decision: Strengthen missing acceptance tests, production monitoring or release safeguards based on causes.
Interpretation trap: More reporting can increase the count while transparency improves. Deduplicate reports and do not suppress defects to keep a dashboard green.

11 · How much capacity is spent correcting preventable work?

Rework share

Definition & measurement: Choose one denominator: correction effort ÷ total tracked effort × 100, or rework items ÷ completed items × 100. Tag a specific cause and keep the two measures separate.
Worked example: A team logs 40 hours correcting misunderstood requirements out of 200 tracked delivery hours: effort-based rework share is 20%.
Data source: Tagged correction work with agreed effort records or work item classification.
Management decision: Use recurring causes to improve discovery, acceptance criteria, collaboration or engineering practices.
Interpretation trap: Learning-driven changes are not automatically waste. Effort tracking has a cost, and inconsistent logging makes exact-looking percentages misleading.

12 · Are people using the delivered capability successfully?

Customer adoption and task success

Definition & measurement: Adoption = active eligible users ÷ eligible users × 100 for a fixed period, with 'active' defined by a meaningful action. Task success = successful qualifying attempts ÷ all qualifying attempts × 100. State exclusions and follow the same cohort over time.
Worked example: 180 of 300 eligible staff use the new workflow during a month: adoption is 60%. Separately, 450 of 500 booking attempts succeed: task success is 90%. These percentages measure different things.
Data source: Product analytics, service records and user research, with privacy-appropriate aggregation.
Management decision: If delivery is fast but adoption is poor, improve usability, training, accessibility or the problem selection—not just throughput.
Interpretation trap: Logins and pageviews can be vanity metrics. Exclude bots/test users consistently and consider who is unable to use the service.

13 · Does delivery improve the problem the investment exists to solve?

Customer satisfaction and business outcome

Definition & measurement: For CSAT, define the survey scale and positive responses: satisfied responses ÷ valid responses × 100. Pair sentiment with an operational measure such as booking completion, processing time or cost per accepted transaction, using a comparable baseline.
Worked example: 72 of 90 valid respondents select the agreed positive ratings: CSAT is 80%, but with a limited sample. Median handling time falls from 10 to 8 minutes: a 20% reduction, not automatically a 20% cash saving.
Data source: Survey with response rate, operational records, baseline dates and a named benefit owner.
Management decision: Prioritise changes that improve the agreed outcome and investigate effects on excluded users or other services.
Interpretation trap: Seasonality, demand, staffing and selection bias affect results. Distinguish correlation, released capacity and realised financial savings.

14 · Can the team keep delivering safely and effectively?

Team health and sustainable delivery

Definition & measurement: Review aggregated trends in a voluntary team-health pulse, interruptions, recurring out-of-hours work and capacity constraints. Agree the survey questions, anonymity rules and review cadence; this is a conversation aid, not a score for employment decisions.
Worked example: A team's pulse declines across three reviews while urgent work consumes an increasing share of its capacity. Discuss on-call load and intake policy rather than celebrating rising velocity.
Data source: Privacy-preserving team feedback, aggregate capacity records and retrospective actions.
Management decision: Remove overload, protect focus time and follow up on agreed improvement actions.
Interpretation trap: Small groups can make anonymous responses identifiable. Avoid individual surveillance, keystroke metrics or linking personal responses to performance ratings.

DORA: measure software delivery, not just board activity

DORA's current model describes five software delivery performance metrics. These are service/application-level signals, not individual targets. Many older dashboards still use the four-metric model; state the version and definitions you use rather than silently treating every incident's mean time to recovery as failed deployment recovery time.

Five DORA software delivery metrics with calculation examples
Metric	Measurement boundary	Illustrative calculation
Change lead time	Elapsed time from a code commit to that change successfully running in production. Summarise comparable changes using a median and upper percentile.	A commit made Monday at 09:00 reaches production Tuesday at 09:00: 24 hours. This is not the same as request-to-delivery lead time.
Deployment frequency	Number of production deployments per service per period, or elapsed time between deployments. State what counts as one deployment.	12 qualifying deployments in four weeks averages 3 per week; inspect their distribution and failure impact, not just the average.
Change fail rate	Production deployments requiring immediate intervention because they degrade service ÷ total qualifying deployments × 100.	2 of 20 deployments require rollback or an urgent fix: 10%. Agree attribution and avoid double-counting one failed deployment.
Failed deployment recovery time	Elapsed time from a failed deployment to restored service. Summarise failed-deployment incidents separately from unrelated service incidents.	A deployment degrades service at 14:00 and service is restored at 15:30: 90 minutes. An alert's closure time is not necessarily the recovery time.
Deployment rework rate	Unplanned deployments made to remediate production problems ÷ all qualifying deployments × 100, using DORA's scope and a documented observation period.	3 of 20 deployments are unplanned remediation deployments: 15%. This differs from change fail rate: one failure may need several corrective deployments.

Join commit, production deployment and incident records using stable references. Record the deployment population, failure criteria, recovery evidence and remediation classification. When there are no deployments, a failure percentage is undefined—not 0%; when there are no failed deployments, show recovery time as not applicable, not instant recovery. Keep reliability and user impact visible alongside these delivery measures.

Do not optimise frequency by issuing meaningless deployments. Short lead times with rising failure or rework indicate an unstable delivery process. Inspect small batch sizes, test automation, release safety and service ownership together.

Tools used in Agile delivery—and how to use their data

Choose the tool after agreeing the workflow. Work tracking, workshop facilitation, engineering telemetry and business intelligence serve different purposes. The following are capability-based comparisons, not endorsements or pricing promises; verify required features, history retention, integrations and access controls for your plan.

Jira

Best fit: Teams needing configurable backlogs, Scrum/Kanban boards and issue workflows.

Define issue types, start/Done statuses, Sprint Goals and blocker fields. Use sprint reports for completed estimates, burn-up/burn-down for scope and control/cumulative-flow reports where supported. Validate how report boundaries map to your actual delivery process.

Evidence to capture: Issue history, sprint membership, estimates, resolution and releases.

Watch out: Workflow changes, reopened issues and mixed estimation units distort charts. Native report availability varies by project type and plan; more advanced history analysis may require exports or an integration.

Jira official information

Azure DevOps

Best fit: Organisations connecting Azure Boards planning with repositories, pipelines and engineering delivery.

Map work item states, area paths and iterations consistently. Boards/Analytics views support flow and sprint analysis; connect release evidence from Pipelines to work items to distinguish Done from deployed.

Evidence to capture: Work item revisions, iterations, pull requests, builds and deployments.

Watch out: State categories and query filters determine which work counts. Cross-team comparisons need compatible boundaries; do not equate a successful build with customer adoption.

Azure DevOps official information

GitHub Projects

Best fit: Software teams wanting issue and pull-request planning close to the code.

Use status, iteration and custom fields; automate transitions where possible. Project Insights can visualise project data. For precise cycle-time or production delivery measures, retain timestamps/history and join issue, pull-request and deployment evidence through exports or APIs.

Evidence to capture: Issues, pull requests, project fields, workflow runs and deployment records.

Watch out: Closed issues are not necessarily released features. Project charts are not a complete DORA measurement system, and current fields alone cannot reconstruct every historical transition.

GitHub Projects official information

Linear

Best fit: Product/software teams preferring lightweight issue handling, cycles and product initiatives.

Agree status boundaries, cycle membership and estimate policy. Use available cycle/Insights reporting to review delivery patterns; join product analytics separately to measure value. Verify required history and export coverage during a trial.

Evidence to capture: Issues, status changes, cycles, projects and estimates.

Watch out: A Linear cycle is not evidence that a team follows Scrum. Advanced analytics availability depends on the product plan, and estimates remain team-local.

Linear official information

Trello

Best fit: Small teams and business workflows needing a simple visual board rather than complex engineering reporting.

Start with explicit Ready, Doing, Review and Done lists, blocker labels and a WIP policy. Record start/completion dates and use exports or a suitable reporting integration for flow analysis. Reconcile counts with actual accepted work.

Evidence to capture: Cards, list moves, labels, dates and checklists.

Watch out: Due dates are not actual start/finish timestamps. Rich cycle-time reporting may need additional tooling; hidden checklist tasks and copied cards can inflate apparent throughput.

Trello official information

Miro

Best fit: Discovery workshops, story mapping, dependency visualisation, value-stream mapping and retrospectives.

Map the customer journey and queues with the team; annotate observed wait times and assign improvement actions to the delivery system. Use the map to interpret KPI trends and identify experiments.

Evidence to capture: Workshop observations, hypotheses, process maps and decisions.

Watch out: Miro is a collaboration surface, not automatically the authoritative delivery ledger. Unmaintained sticky notes cannot support reliable throughput or lead-time claims.

Miro official information

Power BI or Tableau

Best fit: Cross-system reporting where delivery, finance, operations and product outcomes need one governed view.

Build a model with stable item IDs, state-transition events, release links and date tables. Define measures once, display filter context and refresh timestamps, and drill from an aggregate back to its source evidence.

Evidence to capture: Governed extracts/APIs from boards, incidents, deployments, surveys and business systems.

Watch out: A polished dashboard cannot repair missing history. Guard against duplicate joins, timezone mistakes, stale refreshes and unauthorised exposure of customer or staff data.

Power BI or Tableau official information

CI/CD and observability tools

Best fit: Engineering teams measuring software delivery and production reliability; examples include GitHub Actions, Azure Pipelines, GitLab CI/CD and incident-monitoring systems.

Capture production deployment events, source commits, failed changes, recovery events and unplanned remediation deployments. Join them at application/service level and agree incident linkage with operations.

Evidence to capture: Commit, deployment, incident and service recovery timestamps.

Watch out: Pipeline duration is not change lead time. A green pipeline is not a healthy service; coverage, event semantics and failed-deployment definitions matter more than the brand selected.

CI/CD and observability tools official information

Which tool combination fits which situation?

Agile tool selection by delivery setting
Situation	Starting combination	Selection test
Small business-process team	Trello or a simple board plus Miro for mapping; a governed extract for basic measures.	Can you retain actual start/finish events, include blocked work and reconcile completed items without double entry?
Scrum product team	Jira or Azure Boards; product analytics; repository/pipeline integration.	Can goals, accepted Done work and scope changes be linked to releases and customer outcomes?
Developer-centric product team	GitHub Projects or Linear; CI/CD and incident monitoring.	Can issue, code, production deployment and failure events be linked with the metric boundaries you need?
Multiple teams or hybrid governance	A shared data dictionary and Power BI/Tableau over existing systems.	Can each team's work be traced while preserving different workflows, avoiding false velocity comparisons and protecting sensitive data?

How to build a trustworthy measurement workflow

Agree the outcome and decision. Example: reduce the wait for standard access requests without increasing access-control failures. Name the business owner and the delivery owner.
Write a metric contract. Record the KPI name, purpose, calculation, unit, population, excluded records, timestamps, timezone, data source, owner, refresh frequency, baseline, threshold and action. Specify reopened, cancelled and split items.
Instrument the workflow. Keep stable IDs, request/start/completion/delivery events, work type, blocked intervals and release links. Automate capture where feasible; current status alone cannot explain yesterday's flow.
Reconcile a small sample. Pick completed, blocked and reopened items and calculate their values by hand. Compare with reports. Check status mappings, missing timestamps, duplicate joins and estimate changes.
Establish a comparable baseline. Choose a period with enough representative observations, show sample size and work mix, and disclose holidays, staffing changes or unusual incidents. There is no universal minimum sample that makes every metric reliable.
Show context, not only traffic lights. Display trends, distributions, oldest items, scope changes, sample sizes, date filters and refresh time. Do not treat no data as a green result.
Review at the right cadence. Inspect WIP, age and blockers in daily coordination; review goals and outcome evidence at Sprint Reviews; choose process experiments in retrospectives; review benefits with business owners at an agreed longer cadence.
Run one improvement experiment. Set a hypothesis and guardrail, such as reducing review batching while monitoring defects. Name an owner and review date. Compare like-for-like periods and record what changed.
Govern access and retention. Apply least-privilege access, aggregate personal data and retain only necessary history. Keep confidential customer, health and employment data out of open dashboards and unrestricted exports.

A measurement contract in practice

Example measurement definition for standard request lead time
Field	Illustrative definition
Objective	Reduce customer waiting for standard access requests without increasing unauthorised access.
Population & boundary	Standard requests delivered in the reporting week; intake timestamp to confirmed user delivery. Exclude test and cancelled requests, report them separately.
Calculation	Per-item elapsed calendar days; show median, upper percentile with documented calculation method, and sample size.
Source & owner	Service intake + workflow history + delivery confirmation joined by request ID; service owner validates the measure.
Review & action	Inspect weekly trends and daily ageing work; rising lead time with stable cycle time triggers an intake/approval-queue investigation.
Guardrails	Access-control incidents, rework and team workload; no universal target, choose an expectation using the measured baseline.

Read the chart before reacting

Cumulative-flow diagram: widening bands suggest accumulation in a stage. Check state mapping and exits before concluding where the bottleneck is.
Cycle-time scatterplot: inspect the spread and long tail. Annotate large items, expedites and process changes rather than hiding outliers.
Ageing-work view: inspect unfinished items approaching or exceeding their SLE. This complements historical completion charts.
Burn-up: compare completed scope with total scope. If both rise together, delivery may be happening while the release finish moves away.

For reasonably stable flow, Little's Law relates average WIP, throughput and cycle time: average WIP = average throughput × average cycle time, using consistent boundaries and time units. At 12 average active items and 3 completions per day, the implied average cycle time is 4 days. This is a long-run relationship under suitable conditions—not a promise about a single item or a justification for overloading the team.

Business cases: turn measures into management action

Retail checkout: fast releases, weak customer outcomes

Illustrative case: a team completes more tickets each sprint, but abandoned checkouts do not improve.

Measure: Track checkout task success and abandonment for a defined eligible cohort, alongside lead time, escaped defects and production stability. Baseline the existing funnel before release and segment device/payment type without exposing personal data.

Tools & action: Use Jira or Linear for the backlog, product analytics for the funnel and deployment records for release dates. Test a focused checkout change rather than funding more low-value tickets.

Value test: Judge the experiment by successful customer purchases and guardrails such as payment errors. A shorter cycle time supports iteration; it does not by itself validate the business case.

Internal IT requests: the approval queue dominates

Illustrative case: customers complain about a 12-day wait even though active processing usually takes 3 days.

Measure: Separate request-to-delivery lead time from started-to-finished cycle time. Measure ageing work, WIP by stage, blocked reasons and weekly throughput for comparable request types.

Tools & action: Use Azure Boards, Jira or a maintained Trello workflow. Map approvals in Miro; reduce batch approvals and set an explicit review policy and owner. Compare similar periods before and after the change.

Value test: A smaller intake/approval queue is useful only if accepted requests reach users sooner without weakening access controls or increasing rework.

Healthcare portal: quality and adoption are release gates

Illustrative case: a portal team meets its sprint commitments, but integration defects and staff readiness threaten rollout.

Measure: Pair Sprint Goal achievement and flow measures with severe escaped defects, integration-test evidence, service recovery and adoption of the agreed booking journey. Define release criteria with clinical, operational and security owners.

Tools & action: Link board work to testing, production monitoring and staff-readiness evidence. Report only aggregated, authorised health-service data; do not place PHI in public dashboards or generic collaboration tools.

Value test: Do not let rising velocity override safety, privacy or acceptance gates. Re-sequence rollout if the usable end-to-end service and operating support are not ready.

Sources and further reading

Official framework and product references reviewed on 22 October 2026. Local KPI conventions are identified in the measurement definitions; product capabilities can change.

Compare Agile frameworks and choose an approach Understand earned value for cost and schedule governance Connect healthcare technology delivery with operational outcomes