PMI-ACP · Domain 4 of 4

PMI-ACP Domain 4: Delivery

Delivery is tied for the largest share of the PMI-ACP exam and is where agile becomes measurable. It covers getting feedback early, choosing and using agile metrics, managing impediments and risk, removing waste, improving continuously, engaging customers and optimizing flow.

Exam weight
28%
Official tasks
7
Estimated questions estimate
~34
Suggested study time estimate
30–40 hrs

About 17 min read Reviewed October 2026

Overview

Delivery has seven tasks: seek early feedback, manage agile metrics, manage impediments and risk, recognize and eliminate waste, perform continuous improvements, actively engage customers, and optimize flow. It covers the day-to-day mechanics of getting value out the door: small increments, measurable progress, problems found and removed early, and a delivery system that keeps getting faster and more predictable.

Candidates must know which metric answers which question, how to read cumulative flow diagrams and burn charts, how work in progress (WIP) limits and Little's Law affect cycle time, and how lean concepts such as value stream mapping expose waste. The domain applies Mindset's feedback loops and transparency, depends on Leadership's facilitation for retrospectives and impediments, and closes the loop on Product by confirming whether increments delivered value.

How it's tested

Delivery items combine situational judgment with interpretation. Expect to read a cumulative flow diagram, burn chart or metric trend and decide what it means, to choose a metric for a given audience, or to pick the FIRST response to an impediment, risk or quality problem. Correct answers favor small batches, limited WIP, team-involved responses and decisions based on data.

  • Read the chart

    A cumulative flow diagram, burnup, burndown or control chart is described, and you identify the bottleneck, scope change or predictability problem it reveals.

  • Fix the flow

    Work piles up or cycle time grows, and you choose between limiting WIP, swarming, removing a bottleneck or adding capacity.

  • Handle the impediment or risk

    A blocker or emerging risk appears, and you pick the response that involves the team, prioritizes by impact and keeps it visible.

Reasoning it through

A cumulative flow diagram shows the testing band widening every week while the done band grows slowly. A widening band means work enters a stage faster than it leaves, so testing is the bottleneck. The best answer is to limit WIP upstream and have developers help with testing, not to start more development work or simply add a tester without examining the system.

Tasks 7

Official tasks from the PMI outline, in outline order.

4.1 Seek early feedbackDeliver small increments and act on customer feedback often.
What it means
Assess customer satisfaction, deliver in small increments so there is something to react to, and collect and act on stakeholder feedback on a regular rhythm.
What to understand
Small batches shorten the time to learn and reduce the cost of a wrong assumption. Feedback sources include reviews, beta or pilot users, usage analytics and satisfaction measures such as Net Promoter Score; feedback only counts if it changes the backlog.
How it shows up
A team plans to hold all features for one big release, and the best answer is to release a usable subset earlier to real users.
Common confusion
Treating stakeholder sign-off at the end as feedback; early feedback must arrive while change is still cheap.
4.2 Manage agile metricsChoose fit-for-audience metrics, share them and decide with them.
What it means
Select metrics that suit each audience, share them widely, review and analyze them, and use the insights to make decisions.
What to understand
Velocity forecasts a team's own capacity; lead time measures the customer's wait from request to delivery; cycle time measures how long work takes once started; throughput counts items finished per period. Earned value can be adapted to agile, where SPI equals completed points divided by planned points, and metrics should drive conversations, not rewards.
How it shows up
A sponsor asks when a release will finish, and the best answer forecasts from the team's average velocity or throughput, often as a range.
Common confusion
Using velocity as a target or a comparison across teams, which invites inflation and hides real performance.
4.3 Manage impediments and riskFind blockers and risks early; respond, monitor and learn.
What it means
Identify risks and impediments early, involve the team in choosing responses, prioritize removal or mitigation, monitor them, and apply lessons learned to prevent recurrence.
What to understand
Impediments are happening now and block work; risks are uncertain future events. Agile teams treat risk responses as backlog items, review a risk-adjusted backlog, and track exposure with tools such as a risk burndown chart; the daily standup surfaces impediments and the practitioner owns removing those the team cannot.
How it shows up
A team member mentions a blocker in the standup that depends on another department, and the best answer is for the practitioner to take ownership of removing it after the meeting.
Common confusion
Treating risk management as a one-time planning document instead of continuous backlog work.
4.4 Recognize and eliminate wasteMap value flow, find non-value-added work and reduce it.
What it means
Map the end-to-end flow of value to separate value-added from non-value-added work, use metrics and feedback to find waste, prioritize reducing it, and repeat.
What to understand
Value stream mapping shows process time versus wait time; flow efficiency is value-added time divided by total lead time. The lean software development wastes are partially done work, extra processes, extra features, task switching, waiting, motion and defects.
How it shows up
A feature takes six weeks to reach customers but only six days of hands-on work, and the best answer maps the value stream to find and remove the waiting.
Common confusion
Speeding up the busiest step when most lead time is waiting between steps.
4.5 Perform continuous improvementsUse metrics and feedback to change, act and check results.
What it means
Use metrics and feedback to identify changes, implement the improvement actions, and evaluate whether they worked.
What to understand
Retrospectives produce a small number of concrete, owned experiments, and the next retrospective checks their effect. Plan-do-check-act and kaizen describe the same loop; an improvement without a measure or follow-up is only a wish.
How it shows up
Retrospective actions are agreed but never completed, and the best answer is to pick fewer, specific actions with owners and put them in the next iteration's backlog.
Common confusion
Listing many improvement ideas in the retrospective and treating that as improvement.
4.6 Actively engage customersKnow customers' needs, confirm acceptance, collaborate directly.
What it means
Identify customers and their needs, confirm that iteration deliverables meet acceptance criteria, and encourage direct collaboration between customers and the team.
What to understand
Personas, customer interviews and story-writing workshops keep real needs in view. Customer collaboration is an ongoing relationship, not a handoff, and acceptance tests written with customers make expectations explicit before development.
How it shows up
A customer is too busy to attend reviews, and the best answer finds lighter ways to keep them engaged, such as short focused demos or a delegated proxy with authority, rather than proceeding on assumptions.
Common confusion
Assuming the product owner replaces all direct contact between customers and developers.
4.7 Optimize flowLimit WIP, protect focus and use metrics to improve flow.
What it means
Limit work in progress at every level, protect the team from interruptions through mechanisms such as a defined team interface, and use metrics to analyze and improve flow.
What to understand
Little's Law states that average cycle time equals average WIP divided by average throughput, so cutting WIP at steady throughput cuts cycle time. Cumulative flow diagrams show WIP as vertical band width and approximate cycle time as horizontal distance; a widening band marks a bottleneck.
How it shows up
Many items are in progress and few are finishing, and the best answer lowers the WIP limit and swarms on the oldest items.
Common confusion
Believing starting more work keeps people busy and therefore delivers more; high utilization increases queues and wait time.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Little's Law

    Average cycle time equals average work in progress divided by average throughput, for a stable system.

    Remember
    With 20 items in progress and a throughput of 5 items per week, average cycle time is 4 weeks; halving WIP at the same throughput halves cycle time.
    Tested as
    Appears as a calculation or as the reasoning for limiting WIP.
    Trap
    Thinking more WIP means more output; it mainly means longer waits.

  • Lead time vs. cycle time

    Lead time runs from the customer request to delivery; cycle time runs from when work starts to when it is finished.

    Remember
    Lead time is what the customer feels; cycle time is what the team controls most directly.
    Tested as
    Scenarios ask which measure answers a customer's or team's question.
    Trap
    Quoting cycle time to a customer who is waiting on a backlog queue as well.

  • Velocity

    The amount of work, usually in story points, a team completes per iteration, used to forecast its own future capacity.

    Remember
    With 120 points remaining and an average velocity of 30, expect about four more iterations; give a range when velocity varies.
    Tested as
    Used in release-forecast questions.
    Trap
    Setting velocity targets or comparing teams' velocities.

  • Cumulative flow diagram (CFD)

    A stacked area chart of item counts in each workflow state over time.

    Remember
    Band width shows WIP in a state; a widening band means a bottleneck; a flat top line with growing done shows scope is stable.
    Tested as
    Chart-reading questions about bottlenecks and flow.
    Trap
    Reading the tallest band as the bottleneck instead of the band that keeps widening.

  • WIP limits

    Explicit caps on how many items can be in a workflow state or with a person at once, central to Kanban.

    Remember
    When a column hits its limit, people help finish work downstream instead of starting new work.
    Tested as
    The usual answer to growing queues and long cycle times.
    Trap
    Raising the limit when it is reached, which removes the signal.

  • Value stream mapping

    A lean technique that charts every step from request to delivery, showing process time and wait time to expose waste.

    Remember
    Flow efficiency equals value-added time divided by total lead time; low efficiency usually comes from waiting, not slow work.
    Tested as
    Named in the Recognize and eliminate waste task.
    Trap
    Optimizing a single step's speed while queues between steps dominate.

  • Lean software development wastes

    Partially done work, extra processes, extra features, task switching, waiting, motion and defects, adapted by Mary and Tom Poppendieck from lean manufacturing.

    Remember
    Partially done work and task switching are the wastes most tied to high WIP.
    Tested as
    Scenarios describe a practice and ask which waste it represents.
    Trap
    Labeling all documentation as waste; only documentation nobody uses is extra process.

  • Risk burndown chart

    Plots total risk exposure (probability times impact, summed across risks) over time, which should fall as risks are mitigated.

    Remember
    Risk exposure for one risk equals probability multiplied by impact, such as 40% of a 10-day delay equals 4 days.
    Tested as
    Used for monitoring risk and choosing what to tackle first.
    Trap
    Tracking a risk list without prioritizing by exposure.

  • Risk-adjusted backlog

    A backlog in which risk-response actions are added as items and prioritized alongside features by their value in reducing exposure.

    Remember
    High-risk, high-value work is often scheduled early to reduce uncertainty.
    Tested as
    Asked when deciding where risk responses go in agile.
    Trap
    Keeping risk responses in a separate document the team never sees.

  • Earned value in agile

    Agile earned value treats completed story points as earned value, so schedule performance index (SPI) equals completed points divided by planned points and CPI equals earned value divided by actual cost.

    Remember
    SPI or CPI below 1.0 means behind schedule or over budget.
    Tested as
    May appear in metrics or reporting questions for sponsors who expect EVM.
    Trap
    Using EVM without a stable release scope baseline, which makes the numbers meaningless.

  • Retrospective improvement loop

    Team retrospectives identify a few improvements, commit to specific actions, and check their effect at the next retrospective, mirroring plan-do-check-act.

    Remember
    Fewer, owned, measurable actions beat a long list.
    Tested as
    Appears when improvements stall or retrospectives feel useless.
    Trap
    Turning the retrospective into a complaint session with no follow-up.

  • Technical debt

    The future rework cost created by shortcuts in design, code or testing, which slows delivery over time.

    Remember
    Make debt visible and pay it down regularly through refactoring and backlog items.
    Tested as
    Behind scenarios where velocity declines or defects rise.
    Trap
    Deferring all debt until a cleanup iteration that never arrives.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Velocity vs. throughput vs. cycle time vs. lead time

ConceptMeaningKey differenceCommon trap
Velocity Points completed per iteration Forecasts a single team's capacity in iterations Using it as a target or to compare teams
Throughput Items finished per time period Counts items, no estimation needed Ignoring large size differences between items
Cycle time Time from starting work on an item to finishing it Measures the team's process speed Presenting it as the customer's total wait
Lead time Time from request to delivery Includes backlog wait; the customer's view Improving cycle time and assuming lead time fell too

Impediment vs. risk vs. issue

ConceptMeaningKey differenceCommon trap
Impediment Anything currently blocking the team's progress Already happening; removed, often by the practitioner Waiting until the retrospective to raise it
Risk Uncertain future event that could affect objectives May happen; managed through backlog responses Ignoring positive risks (opportunities)
Issue A risk or problem that has occurred and needs resolution Realized; needs action now Leaving it on the risk register as if still uncertain

Burndown vs. cumulative flow diagram

ConceptMeaningKey differenceCommon trap
Burndown Remaining work over time toward a goal Shows progress toward a target, not where work is stuck Using it to locate a bottleneck
Cumulative flow diagram Items in each workflow state over time Shows WIP, bottlenecks and approximate cycle time Reading the largest band rather than the widening one as the bottleneck

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Keep everyone busy

    What candidates pick
    Let developers start new stories while testing is backed up, so nobody is idle.
    Why it looks right
    High utilization feels productive and avoids idle time.
    Why it's wrong
    Starting more work raises WIP, which by Little's Law lengthens cycle time; developers should help clear the testing queue instead.

    Clue to watch for A board or CFD shows work piling up in one state while finished work grows slowly.

  2. Add people to go faster

    What candidates pick
    Add team members to a late release.
    Why it looks right
    More capacity seems like the direct fix for being behind.
    Why it's wrong
    New people need onboarding and add communication paths, often slowing delivery in the short term; scope and flow fixes are usually better first moves.

    Clue to watch for The release is late and the options include adding staff versus reprioritizing scope or limiting WIP.

  3. Velocity as a target

    What candidates pick
    Set a goal to raise velocity by 20% next quarter.
    Why it looks right
    Targets seem to motivate improvement.
    Why it's wrong
    Teams can inflate estimates to hit the number, destroying the metric's forecasting value; improve the system and let the metric reflect it.

    Clue to watch for A manager wants to use velocity to judge or reward the team.

  4. Wait for the retrospective

    What candidates pick
    Note a blocking dependency and raise it at the end-of-iteration retrospective.
    Why it looks right
    The retrospective is the agile place to discuss problems.
    Why it's wrong
    Impediments should be surfaced and removed as soon as they appear, typically from the daily standup, because every day blocked costs flow.

    Clue to watch for The scenario describes work that is blocked today.

  5. Optimize the busiest step

    What candidates pick
    Automate the longest hands-on task to cut lead time.
    Why it looks right
    It targets the visibly slowest work.
    Why it's wrong
    If value stream mapping shows most lead time is waiting between steps, speeding one step barely changes the total; removing queues and handoffs matters more.

    Clue to watch for Lead time is weeks while hands-on work is days.

  6. Too many retrospective actions

    What candidates pick
    Commit to every improvement idea the team raised.
    Why it looks right
    It looks ambitious and inclusive.
    Why it's wrong
    Large action lists are rarely completed; one to three specific, owned actions added to the backlog and checked next time actually change the process.

    Clue to watch for Previous retrospective actions remain undone.

  7. Risk register on the shelf

    What candidates pick
    Update the risk register at the end of each release.
    Why it looks right
    It mirrors formal risk management practice.
    Why it's wrong
    Agile manages risk continuously: responses become backlog items, exposure is tracked visibly, and the team reviews risk during planning and standups.

    Clue to watch for A risk is emerging mid-iteration and the options include updating documents versus acting through the backlog.

Answer framework

For Delivery scenarios, use these steps to diagnose the flow, metric or risk problem and pick the response the exam expects.

  1. Decide whether the scenario is about feedback, a metric, an impediment or risk, waste, improvement, customer engagement or flow.
  2. Read any chart or number carefully: find the widening band, the scope line, or the trend before interpreting it.
  3. Prefer system fixes such as smaller batches, lower WIP, swarming, and removing waits over adding people or starting more work.
  4. Act on impediments and risks now, involve the team in choosing responses, and put the work in the backlog so it stays visible.
  5. Close the loop by checking the result with a metric or customer feedback, and reject options that set metric targets or bury problems.

Practice question

A Kanban team has 24 items in progress and finishes an average of 6 items per week. Customers complain that requests take too long. The team proposes starting more items each week to increase output. What should the agile practitioner recommend?

Want more like this? The PMI-ACP practice test has questions for every domain.

Checklist

0 of 13

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start Delivery with flow, because it underpins the most questions: WIP limits, Little's Law, cumulative flow diagrams, and the difference between cycle time and lead time. Work a few Little's Law calculations by hand and sketch a CFD with a bottleneck until reading one feels automatic.

Next, cover metrics as a set. For each of velocity, throughput, cycle time, lead time, burn charts and agile earned value, write down the question it answers and who asks it. Then study waste through value stream mapping and the lean wastes, and risk through risk exposure, the risk-adjusted backlog and the impediment-versus-risk-versus-issue distinction.

Commonly underestimated areas are Actively engage customers and Perform continuous improvements, which look simple but test specific behaviors: keeping customers involved when they are busy, and turning retrospectives into a few measured experiments.

Afterwards, take mixed practice sets, since Delivery questions often combine a chart with a situational decision. Review misses by asking whether you chose a system fix or a people-and-effort fix; the exam favors the system fix.

FAQ

How much of the PMI-ACP exam is Delivery?

Delivery is 28% of the exam, tied with Mindset as the largest domain. Our planning estimate is about 34 of the 120 items, though PMI does not publish per-domain question counts.

Do I need to do calculations in Delivery?

Be ready for simple ones: Little's Law, velocity-based release forecasts, risk exposure, and agile earned value indices such as SPI and CPI. Chart interpretation is at least as common as arithmetic.

What is the difference between lead time and cycle time?

Lead time runs from the customer's request to delivery and includes time waiting in the backlog. Cycle time starts when the team begins work on the item and ends when it is finished.

How do I find a bottleneck on a cumulative flow diagram?

Look for the band that keeps getting wider over time, meaning work enters that state faster than it leaves. The bottleneck is that state, or the state that is failing to pull from it.

How is risk handled differently in agile?

Risk responses become backlog items prioritized alongside features, risks are reviewed continuously in planning and standups, and exposure is tracked visibly, for example on a risk burndown chart.

How does Delivery connect to the other domains?

It applies Mindset's feedback loops and transparency, relies on Leadership's facilitation for retrospectives and impediments, and confirms whether Product's increments actually delivered value.

How long should I study Delivery?

Our planning estimate is 30–40 hours within a 120-hour plan, with a good share on chart reading and short calculations.

Other Project Management certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have covered feedback, agile metrics, flow and WIP, waste, risk and continuous improvement. Test whether you can read the charts and choose the system fix under exam conditions.

Take the PMI-ACP practice test Check your PMI-ACP readiness

Keep going