PMI-ACP Agile Metrics: Velocity, Throughput, Cycle Time, Lead Time and Forecasting

Managing agile metrics means choosing a small set of measures that answer real questions, showing them openly to the people who need them, reading them carefully over time, and using what they reveal to make decisions about scope, dates, investment and the way the team works. The PMI-ACP Examination Content Outline makes it Task 2 of the Delivery domain and lists four enablers:

1. Determine which metrics are appropriate for a given audience. The team, the product owner, sponsors, finance and customers each make different decisions, so each needs different measures.
2. Radiate metrics across the relevant audience. Make current, explained data available to whoever needs it, without them having to ask.
3. Review and analyze metrics. Look at trends and context, not single data points, and normalise before comparing.
4. Use metrics insights for decision making. A metric that never changes a decision is waste.

Separately from the tasks, the outline has a general tools-and-techniques list. Its Metrics entry names velocity, throughput and productivity, cycle time, lead time, EVM for agile projects, defect rates, approved iterations and work in progress, and its Planning, Monitoring, and Adapting entry includes variance and trend analysis. The list is not mapped to individual tasks, but most of these measures are what this task works with.

Neighbouring tasks own related material. Reading burndown, burnup and cumulative flow charts and designing boards belong to Visualize work; agile earned value and measuring the delivery of value to Manage increments; vanity versus actionable outcome measures to Manage value delivery and Experiment early; information-radiator basics to Build transparency; WIP limits and using flow metrics to improve flow to Optimize flow; waste measures to Recognize and eliminate waste; and judging whether an improvement worked to Perform continuous improvements.

Each core agile metric answers one specific question, and most misuse comes from asking it a different one. Know what each measures, who it is mainly for, and what it cannot tell you.

Productivity in agile is read at team level and over time. A rising number of finished items per team-week, with quality holding, says the team's system is getting more effective; a falling one is a prompt to look for impediments, not for someone to blame. Because it depends on how work is sliced and what kind of work it is, it is a trend for one team, not a league table.

Approved iterations track acceptance rather than activity. The outline lists the term without defining it; in practice it means counting the iterations whose output the product owner or stakeholders accepted at review. A run of accepted increments shows delivery the business recognises; an increment that is not accepted points to a gap in shared understanding of the work or of done, which is worth raising at once rather than discovering at release.

Velocity, throughput and productivity measure output; outcome measures show whether that output achieved anything. A healthy metric set includes both, aimed at different audiences.

Lead time runs from the moment something is requested until it is delivered; cycle time runs from when the team starts work on it until it is done. Lead time is what a customer or requester experiences. Cycle time is the part the team directly controls. The difference between them is waiting: time in a queue before anyone starts, and time after the work is finished but before users get it.

A worked illustration: a change request sits in an intake queue for three weeks, is worked for four days, then waits a week for a deployment slot. Its cycle time is four days; its lead time is about a month. Making the four days faster barely changes what the requester experiences. That is why a team whose cycle time is short can still be seen as slow, and why lead time, broken into its waiting and working parts, is where to look for the delay.

How you express it matters as much as which span you choose. An average is exceeded by a large share of items, so a promise based on an average is broken often. A percentile (for example, "90% of requests are delivered within 18 days") states a figure most requests meet. When you tell requesters what to expect, use lead time, because their clock starts when they ask, and express it as a percentile chosen for how rarely the promise may be broken.

The right metric for an audience is the one that informs the decision that audience actually makes, in terms it understands, at the cadence it looks. Start from the decision, then pick the measure.

Two principles sit behind the table. First, detail shrinks as the audience moves away from the work: a sponsor deciding on funding needs results and a forecast, not a day-by-day view of tasks. Second, anything denominated in story points stays inside the team that estimated it. Story points are relative to each team's own scale, so they have no meaning to customers or finance and cannot compare teams, however they are rescaled. Counts of items are no fairer across teams, because each team slices work differently. Value for money is judged in money and outcomes.

The team chooses its own working metrics. A long list imposed from outside tends to be updated and ignored. Help the team pick a few metrics that answer questions it actually has ("how long do items wait for a code review?"), review them regularly (for example, in retrospectives), and prune any metric that no longer changes a decision, especially one that costs effort to compile. Ownership of the team's working metrics stays with the team; it does not need outside approval to add or drop one.

A lagging indicator confirms a result after it has happened; a leading indicator moves earlier and predicts that result, so you can still steer. Annual revenue, churn over a year, quarterly support costs and last iteration's velocity are lagging. Rising WIP, ageing items in progress, and early user behaviour after a release are leading.

A good leading indicator has two properties:

• It moves early, within days or weeks rather than months.
• It is causally linked to the outcome and, ideally, moved only by the change you are judging. A metric that also responds to seasonal effects, marketing campaigns or simple curiosity (page views rather than completed actions) gives a noisy or misleading signal.

For delivery, the most useful early warnings are work in progress and item age. In a stable system, average cycle time grows with average WIP for a given throughput (Little's Law), so rising WIP predicts longer delivery before dates are missed, and an item that has sat in progress far longer than its peers is stuck now. Figures that are fixed at the start of an iteration, or that record effort rather than finished work, cannot give that warning.

For product outcomes, pick a completed user action that should come before the result and that only the new feature affects. Suppose a redesigned checkout is meant to raise annual online sales: the completion rate of checkouts started on the new flow moves within days, while total visits would also swing with promotions and the season. Keep the lagging measure too; it confirms whether the leading indicator really predicted the outcome.

Velocity is a team's own average of completed estimated work per iteration, used to forecast how much that team can take on. It is not a measure of value, of productivity relative to other teams, or of individual contribution, and it is only trustworthy if the rules for counting it stay honest and stable.

• Count only done work. A story either meets the definition of done and counts in full, or it counts nothing. Partial credit inflates velocity, makes progress look better than the working software supports, and breaks the forecast.
• Re-baseline after a significant team change. Velocity belongs to a particular team. When people leave or join, the old average no longer applies, and arithmetic scaling by headcount is false precision because knowledge and ramp-up are uneven. Plan cautiously and let the first few iterations of the changed team set the new baseline.
• Re-baseline after a process change. A stricter definition of done puts more work into every story, so velocity usually drops. That lower figure is the honest measure of the new way of working, and it becomes the baseline. Velocity is only useful for planning while the estimating scale and the definition of done stay constant, so neither should be adjusted to make the number look like it did before.
• Normalise when the iteration length changes. If a team moves from one-week to two-week iterations, points per iteration roughly double with no change in pace. Compare points per week (or per available person-day) before concluding anything.

Because velocity is an estimate-based figure, demanding more of it does not create capacity. Pressure on the number tends to change how work is estimated, or how carefully it is done, rather than how much is delivered.

When a metric becomes a target, people improve the number rather than the thing it was meant to reflect; the remedy is to pair it with a balancing metric that gaming would make worse and to keep the unit you count stable. This is often summarised as Goodhart's law.

How to recognise gaming:

• The number improves while related measures worsen. A support group targeted on tickets closed per day starts closing tickets before customers confirm the fix; closures rise and so does the reopen rate.
• The unit of work changes shape. Targets on velocity tend to inflate estimates; targets on item counts or on speed per item tend to produce smaller and smaller slices, often technical tasks rather than user-visible stories.
• Individual targets erode teamwork. Ranking people on points or hours logged rewards looking busy and discourages helping others.

How to design against it:

• Balance speed or volume with quality and value. For each output metric, ask what a team could do to move it the wrong way, and watch a measure that would expose that: a quality measure such as escaped defects or reopen rate, and a value measure such as adoption of what was delivered. A balancing metric has to move against the shortcut; a second volume or activity figure moves with it.
• Count a consistent unit, such as finished user-visible stories, so slicing tricks do not change the count.
• Keep planning metrics as aids and set goals on outcomes. Velocity serves the team's planning; business goals are stated as results.
• Keep productivity measures at team level. Individual activity counts (hours, points per person) measure effort rather than results, invite blame and misrepresent work done as a team.

Review metrics as a series over several periods against their own normal range, and normalise for anything that changed, before deciding that performance has changed. This is the variance and trend analysis the outline lists under planning, monitoring and adapting.

• One data point is not a trend. If a team's median cycle time has moved between 3 and 6 days all quarter, a 6-day week is normal variation and needs no intervention; reacting to every wobble adds disturbance. Look for a sustained shift, a run in one direction, or a value outside the usual range.
• A trend matters even below a threshold. Failed deployments of 1, 1, 2, 3, 3 and 4 a month against an alert level of 6 have triggered nothing, but a steady climb is itself the signal. Investigate the cause with the team while it is small, before choosing any fix.
• Normalise counts by volume. A team that shipped 50 items with 10 escaped defects (20%) and then 80 items with 12 (15%) has more defects but a better defect rate. Compare rates, not raw counts, when volume changes.
• Normalise by time and capacity. Velocity falls in an iteration with public holidays or people on leave. Work out the pace per available person-day; if capacity explains the drop, the pace is unchanged. Plan the next iteration from its own expected capacity, rather than adding the shortfall to it.
• Look for work the metric does not count. If a team quietly takes on unplanned work that never appears on the board, the throughput of planned work falls even though the team is just as busy. Make that work visible and measure its share, so the trade-off can be discussed openly.
• Look behind steady numbers too. Steady velocity can hide a growing share of each iteration spent on rework. Track the rework share and show its trend to the product owner, who weighs quality work against new features; keeping the cause visible is what lets it be fixed.

Agile forecasts use the team's own historical velocity or throughput to give a range of likely finish dates with stated confidence, not a single date. A date computed from the average is often missed, roughly half the time when the data are evenly spread; a date computed from the best period is missed far more often. Both hide the uncertainty that the history plainly shows.

Monte Carlo simulation resamples past throughput (for example, picking a random historical week, again and again) to simulate many possible futures, and reports how many of them finished the remaining work by each date. "90% by 14 June" means that in 90% of the simulated runs, all of the remaining work was done on or before 14 June. It does not mean 90% of the work will be done by then, and it is not a measure of the team's opinion.

Choose the percentile by the cost of missing the date, not by habit. The more a miss would cost, the higher the confidence the date should carry, and the later that date will be. Percentile dates are read individually; averaging them produces a number with no statistical meaning.

Two checks before trusting any throughput-based forecast:

• Net burn, not throughput alone. If new items keep arriving in the release, the backlog shrinks only by completions minus arrivals. A team finishing 10 to 12 items a week while 4 are added is burning down only 6 to 8 a week. Use the measured arrival rate rather than a guessed buffer.
• Like-for-like items. Throughput blends every kind of item. If the mix shifts, for example towards many small fixes, the count can rise while the work you are forecasting slows. Forecast a backlog from the finish rate of the same kind of item.

Radiating metrics means making them continuously visible to their audience, so anyone can see current, explained data without asking; using them means bringing what they show to the people who own the decision while there is still time to act.

Radiate rather than report. A pushed report is a snapshot that ages quickly and costs the team effort to prepare. A dashboard updated automatically from the team's own tools is always current and available whenever someone looks, which matters most when stakeholders are spread across locations and time zones.

A radiated metric needs three things to be read correctly:

• a definition of what it counts;
• the date the data was last updated, so nobody acts on stale figures;
• a trend over several periods beside the current value, so viewers can tell normal variation from a real change.

Keep individual figures off shared dashboards; they invite comparison and blame and mean little to outside viewers. Refresh at the cadence people look.

Radiate bad news too. When a forecast or a trend turns the wrong way, it stays visible, with context: what caused it and when options will be ready. A radiator that shows only good news stops being trusted, and trust is what it exists to build.

Use the insight early, with the decision owners. A forecast is worth most while choices remain. When it shows that the planned scope and the date no longer fit, the product owner takes that to stakeholders straight away to trade scope, order or date; each iteration of waiting removes options. Remember that capacity is not a quick lever: pressure on velocity distorts estimates, and people added late need time before they help.

Break a problem metric down before investing. Split a long lead time into its stages and see where the time goes. If most of it is spent waiting, for example in a change-approval queue, the biggest gain comes from shortening that wait, not from improving stages that are already quick.