PMI-ACP Manage Value Delivery: Success Criteria, Optimizing Increments and Proving Results

Managing value delivery means deciding, before work starts, what value the product must create and how it will be measured; shaping each increment so the most value reaches people soonest for the least effort; and checking after release that the targeted results were actually achieved. It is the task in the Product domain of PMI's PMI-ACP Examination Content Outline that connects everything the team builds to the reason someone paid for it.

The outline lists three enablers for Manage value delivery, and they give this lesson its structure:

1. Define what value will look like (for example success criteria, sustainability, security, privacy, regulatory and compliance obligations).
2. Ensure the value increments are optimized.
3. Ensure that the targeted results are achieved (for example customer satisfaction or an increase in sales).

The three form a loop. A value definition sets measurable targets; increments are shaped and sequenced to move those targets; results are measured against the targets after release; and what the measures show changes the backlog for the next increment. The Agile Manifesto's first principle states the aim: our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Delivering features is the means; the outcome the features produce is the value.

Neighbouring tasks own some related material. Ordering techniques such as MoSCoW, Kano and financial measures (ROI, NPV, IRR) belong to Refine product backlog. Increment goals, the definition of done as a quality bar, iteration reviews and value burnups belong to Manage increments. Information radiators belong to Visualize work. MVPs and hypothesis experiments are covered with early experimentation in the Mindset domain, and feedback collection with the Delivery domain. This lesson covers what is distinctive here: defining value completely, optimizing increments for value, and proving the result.

Value is defined by writing success criteria: measurable statements of the change the product must cause for customers or the business, agreed with the sponsor and key stakeholders before the team builds. Without them, nobody can tell months later whether the investment worked, and every debate about priorities turns into opinion.

A usable success criterion has four parts:

• An outcome: a change in behaviour or business results (time to complete a task, repeat use, contact volume, revenue), not a list of features.
• A baseline: where the measure stands today, so a change can be shown.
• A target: the value that counts as success.
• A timeframe: when the target should be reached.

For a city council's online parking-permit service, "residents will like the new service" has none of these. "Cut the median time to complete a permit application from 12 minutes to 4 minutes within two quarters" has all four. Research, prototypes and delivered pages can support such a criterion, but they describe the work, not the change it is meant to cause.

Velocity is a capacity-planning measure for the team; it says nothing about whether customers are better off, so it does not belong in a success criterion. A fixed, signed-off scope fixes the outputs in advance, which is the opposite of what an agile value definition is for: scope may change as long as the outcome is reached.

Leading and lagging measures

Many business outcomes are lagging: yearly retention, annual revenue or membership renewals are only known long after the work that influenced them. A team releasing every couple of weeks also needs a leading measure: a customer behaviour visible within weeks of a release that is expected to drive the lagging outcome. A good leading measure has three properties: it is something customers do (not what anyone predicts or says), it can be observed soon after each release, and there is a plausible causal link to the lagging outcome. For a gym chain whose target is annual membership retention, the share of new members who attend at least twice a week in their first month is such a measure. Pair each lagging outcome with a leading behaviour measure, and check from time to time that the two really move together; if they stop moving together, the leading measure needs replacing.

Value is defined together with customers and stakeholders, reconciled against the organization's goals, and then turned into an order of work by the product owner. No single group owns the definition, and no single group's measures are enough.

Buyers and users are different stakeholders. The party that pays for a product (a purchasing team, a client's IT group, an executive sponsor) usually cares about cost, contract terms and control. The people who use it every day care about whether it makes their work easier. A school district may buy a lesson-planning platform on price and data-protection terms, but if teachers find it slower than their own spreadsheets, it will sit unused and deliver nothing. Complete success criteria therefore carry both: the buyer's measures and the users' adoption and experience measures.

When stakeholders disagree about what success means, the agile practitioner brings them together and facilitates agreement on a shared set of value measures that everyone can see the work judged against. Collaboration comes first; escalation is for when collaboration has genuinely failed. Two principles guide the outcome: capacity follows value rather than an even share for each group, and business decisions about value stay with the business, not with the developers.

Aligning to the organization. Each group's proposed measures are checked against the organization's stated goals, such as a company-wide objective to reduce costs or grow a market. Measures that serve the goal stay; ones that pull against it are discussed openly. After hearing every group, the product owner decides the order of the work, keeping a single, coherent value definition rather than one per group. Facilitation and alignment inform that decision; they do not replace the product owner's accountability for it.

A product that is insecure, mishandles personal data or cannot legally ship has no value, however popular its features. PMI's outline names security, privacy, regulatory and compliance obligations as part of what value will look like, so they are defined up front and built into every increment rather than checked once at the end.

Security in every increment

Every increment that reaches users is reachable by attackers too, so security is built in and verified at the same rhythm as delivery. Assurance concentrated at the end of a long programme finds flaws late, when they are expensive to fix and users have already been exposed through earlier releases. The agile approach is to give each increment security criteria and to verify them continuously, with automated checks in the delivery pipeline and security specialists reviewing as the work is done. Periodic external testing can complement this, but it does not replace security built into each increment. Security is treated as a property of the work, not as separate work.

Where a security requirement is recorded depends on its scope:

The test is simple: if the rule should hold for everything the team finishes, it belongs in the definition of done; if it describes how one feature must behave, it belongs in that story's acceptance criteria.

Privacy by design

Privacy by design means designing privacy into the product from the first increment instead of adding it later. Its core practices:

• Data minimization: collect only the personal data the stated purpose needs. Data gathered on the chance it might be useful adds risk and, under laws such as the EU GDPR (Article 5), may not be lawful at all. Any data that is collected has to be protected, retained and eventually deleted, so the safest data is the data never collected.
• Purpose stated per story: each story names which personal data it needs and why, so unnecessary collection is visible when the story is refined.
• Privacy by default (GDPR Article 25): the protective setting is the starting setting; for a library app, borrowing history is not shown to anyone else unless the member chooses to share it.
• Built into the increment that collects the data: consent, the ability to delete and retention limits ship in the same increment that first collects a piece of personal data, so no release ever holds data without those protections.

Privacy by design is related to, but different from, other security ideas:

For a product that stores sensitive personal records, both privacy and access control belong in the definition of value: what data is collected and why, and who may see it.

Regulatory and compliance obligations

If the law requires an auditable record, traceability from requirements to the tests that verified them, or specific tax or data-handling rules, the product cannot ship without them, so they are part of its value even though customers never ask for them. The compliance officer or the regulator's representative is treated as a stakeholder throughout: helping define the criteria at the start and reviewing each increment as it is built, so problems surface when they are cheap to fix rather than just before launch. Compliance becomes part of the work, not a gate after it.

A product owner may see a regulatory obligation as paperwork with no customer value and rank it low. The agile practitioner's role is to coach: explain that without the obligation the product cannot be released or sold, so it carries the value of everything that depends on it. The product owner stays accountable for the ordering, now with the full picture; the practitioner informs that decision rather than taking it.

The same reasoning decides scope cuts. When a release must shrink to keep its date, the obligations the release legally or safely cannot do without stay in; nice-to-have features and capacity for users who do not yet exist are the candidates to cut.

Sustainability in a value definition means the product and the team can keep delivering value over time. It has three faces in agile practice: technical debt, a sustainable working pace, and, where the organization has committed to them, environmental targets.

Technical debt

Technical debt is the future cost of shortcuts in design or code: every later change takes longer and is more likely to break something. Its symptoms are falling velocity and rising defects reaching customers. Because debt slows the delivery of future value, it is a product decision, and the product owner needs it presented in value terms. For each debt item, the team states two things: the effort to repay it, and how much it slows future feature work (or how much risk it adds). With both, the product owner can compare repaying a debt item against building a feature with the same capacity, using the same value reasoning as any other backlog choice.

When debt is visibly hurting delivery and repayment keeps losing out to features, the agile practitioner makes the cost of the debt visible and helps the product owner and developers agree a repayment plan together, so the decision is shared and stays inside the normal backlog. The aim is a steady, planned balance between new value and paying down debt.

Debt can also be taken on deliberately. Martin Fowler's technical-debt quadrant calls this deliberate, prudent debt: "we must ship now and deal with the consequences". If a time-critical opportunity, such as a demonstration at an annual trade fair, can only be met with a simplified design, shipping it can be the right value decision, provided the rework is made visible and scheduled as backlog items. Debt that is taken on but not tracked becomes unmanaged debt, which grows quietly until it slows everything.

Sustainable pace

The Agile Manifesto states that sponsors, developers and users should be able to maintain a constant pace indefinitely. Long stretches of evenings and weekends produce more defects and burnout, which destroy value faster than the extra hours create it. When a date and a sustainable pace conflict, the agile practitioner helps the team return to a sustainable pace and works with the product owner to replan scope. The levers are scope and order; hours, quality and the definition of done are not.

Environmental sustainability

Where an organization has made public commitments, such as cutting the energy its systems use, and the product contributes materially to that footprint, the target belongs in the product's success criteria alongside its business measures. Only measures that sit in the success criteria take part in trade-off decisions; a target kept elsewhere cannot influence how the product is designed or what is prioritized.

An increment is optimized when it delivers the most value for the least work. The Agile Manifesto principle behind this is simplicity, the art of maximizing the amount of work not done. Every hour spent on something nobody values is an hour not spent on something they do.

Gold plating is adding features, polish or options beyond what was asked for or valued, for example a developer giving an internal room-booking screen custom colour themes and a printable calendar view that nobody requested. It feels like generosity but consumes capacity, adds code to maintain and delays valued work. It is a failure of simplicity, not of technical excellence: good design means clean, maintainable work on what is actually needed.

Three patterns optimize an increment:

• Deliver the common case first. When most demand follows a simple path and a small share needs complex rules, release the simple path early so most customers get value now, and keep serving the complex cases another way (such as manual handling) until they are automated. For a parcel company, that might mean automating the standard redelivery request first while unusual international cases stay with the service desk for a while. Nobody is abandoned, and the majority is not kept waiting for the minority.
• Build for the need you have. Speculative generality, building flexibility for customers or uses that do not yet exist, adds cost now for value that may never arrive. Build what the current customer needs and add flexibility when real demand appears; well-factored code keeps that later change cheap.
• Defer or simplify low-value scope. Each increment carries its high-value core; marginal items wait in the backlog, where they may turn out to be unnecessary.

Increments are sequenced so that the most value is realized soonest, and cost of delay is the measure that makes this explicit: the value lost for each period a capability is not yet in use. Weighted shortest job first (WSJF) divides cost of delay by the job's duration (or size) and does the highest score first. It comes from Don Reinertsen's work on product-development flow, and is also known as CD3 (cost of delay divided by duration). SAFe uses a version in which cost of delay is estimated from user-business value, time criticality and risk reduction or opportunity enablement, divided by job size.

A worked example, with cost of delay per week and duration in weeks:

Q goes first, then P, then R, even though R has the largest cost of delay: a small job with a meaningful cost of delay releases value quickly and then stops costing anything. The division matters; ranking by cost of delay alone favours large, slow jobs.

Enablers carry the cost of delay they hold back

Technical enablers, such as a database migration or a new identity service, deliver nothing customers can see, so a naive score puts them last. But if planned features cannot start until the enabler is done, the enabler's cost of delay includes the value those features are held back by. Price that in, and an enabler that unblocks several valuable features often belongs first. Doing one item at a time in WSJF order generally realizes value sooner than spreading the team across everything at once.

Slice, then re-score

Large items score poorly because their duration is long, even when most of their value sits in a small part. If a short first slice of a large feature captures most of its cost of delay, treat the slice as its own item and score it: it often ranks highest. The remainder then becomes a separate item, re-scored against everything else with the smaller cost of delay that is left. For example, a 12-week feature with a cost of delay of $36,000 a week scores 3,000; if a 3-week slice captures $27,000 a week of it, the slice scores 9,000 and the 9-week remainder, with $9,000 a week left, scores 1,000.

Value is realized only when an increment is in use by the people it was built for. A feature that is done but waiting for a release window, or released but ignored, has cost money and produced nothing yet.

Release the most valuable piece early

When one capability alone would serve most of the demand and can be ready long before the full product, releasing it first and adding the rest in later releases starts the return early, and real use informs what comes next. The principle is incremental release: value reaches users in the order of its size, not when the last planned capability is complete.

Shorten the path from done to in use

If finished increments wait a long time for approvals and deployment, the team's speed never reaches customers; building faster only lengthens the queue. The first step is to understand where the time goes: map the path from done to in use with the people who own each stage, such as operations, release management and approvers, in effect a value stream map of the release process. That shows where work waits and why, so the organization can redesign the flow, for example with smaller, lower-risk changes and automated evidence, while keeping the controls it needs.

Adoption: released is not realized

Sometimes the product is released and still not used. Adoption depends on what surrounds the product as well as on the product itself: habits, the reports and reviews that managers still run from the old tools, and incentives tied to the old way of working. If a hospital's new shift-swap app works but ward managers still approve swaps from a paper rota, staff will keep using paper. The product owner works with the users and their managers to move those surrounding practices onto the new product. Value is counted when behaviour changes, not when the release goes out.

Let usage data optimize the next increments

Usage analytics show what customers actually do; interviews and surveys show what they say and why. Both are needed, but they answer different questions: when the question is whether customers rely on something day to day, direct evidence of behaviour comes first, and opinions, requests and complaints are indirect signals to interpret alongside it. Usage is then read together with satisfaction:

Low usage is a question, not an answer: learn why before acting, because the few customers who do use a feature may depend on it heavily.

Targeted results are measured with the outcome measures agreed in the success criteria, such as customer satisfaction or an increase in sales, using measures that move only when the outcome moves.

Customer satisfaction measures

Choose the measure that matches the aim. A change meant to make a task easier or quicker is judged by effort (CES), asked right after the task; satisfaction with a particular experience by CSAT; loyalty over time by NPS. Prioritization models such as Kano classify features by how they affect satisfaction, but they are not satisfaction scores.

Calculating NPS. Respondents scoring 9 or 10 are promoters, 7 or 8 passives, and 0 to 6 detractors. NPS is the percentage of promoters minus the percentage of detractors, on a scale from -100 to +100. Passives are not subtracted, but they count in the total. Example: of 400 respondents, 180 are promoters (45%), 140 passives and 80 detractors (20%), so NPS = 45 - 20 = 25.

Vanity versus actionable metrics

A vanity metric can rise while the targeted result stays flat: installs, sign-ups, page views, gross order counts. An actionable metric is tied directly to the goal, so its movement means the goal is moving: weekly active users for an engagement goal, paid conversions and revenue against baseline for a sales goal. A useful test is to ask: could this number improve while the goal does not? If yes, it is not the measure of success.

Honesty with the sponsor follows from this. If a promotion sends visitor numbers soaring but the agreed outcome has not moved, the product owner reports plainly that the targeted result has not been reached yet. The success measure was agreed in advance; changing it after the fact to whatever went up is moving the goalposts.

A headline measure for an outcome should express that outcome as directly as possible. For a sales goal, that means money actually kept, revenue net of cancellations and returns, rather than activity that may later be reversed. Ratios such as conversion rate or average order value are diagnostics beneath the headline, useful for explaining why the outcome moved.

A targeted result is achieved when the agreed measure has reached its target against the baseline, the change can be attributed to the product, and nothing important was harmed along the way. Checking all three comes before declaring success and closing the work.

• Compare with the baseline: use the outcome measure itself, before and after, rather than work completed, activity counts or anecdotes.
• Check side effects: look at what else the change affected, including complaints, cancellations, errors and, for security-sensitive changes, incidents. A target met by making things worse for customers elsewhere is not the value that was funded. When a side effect appears, the first step is to understand its cause with customers and data; the right fix depends on what that shows.
• Attribute the change: if something else changed at the same time, such as a promotion, a competitor leaving the market or seasonal demand, separate the product's effect from it (with a comparison group, a staged rollout or the earlier trend) before claiming the result. The aim is a fair estimate of the product's share, not crediting all or none of it.

When the results are not coming

When the targeted result is flat or behind after several releases, the agile response is inspect, then adapt: find out why with customers and data, then change the backlog or direction to address the cause. Inspection means looking at the evidence closest to the problem: where users drop out of a journey, what the people who talk to customers every day are hearing, what usage shows. For example, a city's recycling-collection app meant to cut missed-collection reports might reveal that most reports come from flats whose bins are collected on a different day from the street; fixing that data would then move ahead of planned features.

A plan written before release was a hypothesis; results that fall short are evidence against it. Carrying on with the plan regardless, adjusting the target or deadline to fit, or changing direction without understanding the cause all act before learning. Reporting the shortfall to the sponsor is right and transparent, and it comes together with a plan to find the cause and adapt.

This loop, define, deliver, measure, inspect, adapt, is what turns a value definition from a document into a way of steering the product.