PMI-ACP Manage Increments: Iteration Goals, Definition of Done, Reviews and Measuring Value

Managing increments means making sure that each small, working piece of the product a team finishes serves the business's current priorities, has a clear goal, is shown to the right people early enough for their feedback to matter, and is measured by the value it actually delivers. An increment is the sum of done, usable work a team produces in an iteration (a sprint in Scrum) or, in flow-based teams, in a release cycle, added to every increment delivered before it. It is the unit through which an agile team turns a product backlog into something real people can try.

The PMI-ACP Examination Content Outline lists Manage increments as a task in the Product domain, with four enablers that give this lesson its structure:

1. Ensure increment is aligned with business priorities.
2. Define the increment goals.
3. Demonstrate increments of value for early feedback.
4. Measure the delivery of value.

The enablers form a loop. Business priorities set the order of the backlog; the top of that backlog becomes an increment with a goal; the finished increment is demonstrated and often released; feedback and value measures go back into the backlog and reshape the next increment. Each turn of the loop shortens the distance between what the team builds and what the business and its users need.

The roles matter throughout. The product owner (or whoever holds that accountability) is responsible for value: ordering the backlog, deciding what is released and when, and turning feedback into backlog items. The developers decide how to do the work and how much they can take on. The agile practitioner (scrum master, coach or agile project manager) facilitates and coaches so that both happen well, rather than deciding for either of them.

Scope note: writing, splitting and sizing backlog items and the prioritization techniques themselves (MoSCoW, Kano, weighted shortest job first) belong to the sibling task Refine product backlog. Keeping information radiators current is Visualize work. Defining success criteria for the whole product and confirming that targeted business results are achieved is Manage value delivery. This lesson stays with the increment: its alignment, its goal, its demonstration and the measures that show whether it delivered.

An increment is aligned with business priorities when the team builds it from the top of a product backlog that the product owner keeps ordered by current business value. Alignment is not checked after the fact; it is designed in. If the backlog order reflects what the business needs most right now, and the team pulls its work from the top of that order, every increment delivers the most valuable work available at that moment.

That gives two practical duties:

• Keep the order current. Business priorities move: a strategy review shifts the focus to a different customer segment, a regulation lands, a competitor launches. A backlog last ordered months ago may still put yesterday's priorities at the top. Before work is selected at planning, the order should be checked against the current goals. Ordering is the product owner's accountability, so the agile practitioner's contribution is to make any mismatch between the order and the current goals visible to the product owner in time for the order to be corrected before work is selected.
• Pull from the top. The developers decide how much they can take on, but what they take comes from the top of the order. If a team habitually selects work further down the order for its own preferences, its increments drift away from what stakeholders need. The agile practitioner treats that as a team-level pattern: make it visible early and coach the team and the product owner through it together, using transparency rather than authority. The developers can and should raise genuine reasons to take items out of order, such as a technical dependency or a risk worth reducing early, but the product owner makes that call in the open.

Alignment also runs upward. The increment should move the product toward its product goal or release objective, and those in turn should serve the organization's strategy. How the vision stays connected to organizational goals is covered in the Leadership domain's lesson on shared vision and purpose; here, the point is that the increment is where that alignment either becomes real or quietly fails.

When business priorities change during an iteration, the usual response is to reorder the product backlog so the new priority is next in line, and to leave the current iteration running toward its goal. Iterations are short precisely so that the business never has to wait long: a new priority can usually be started at the next planning session, typically within one or two weeks, without disrupting work already under way.

Protecting the iteration is not stubbornness. Constant mid-iteration changes destroy focus, waste partly finished work and make the team's forecasts meaningless. So the agile mindset holds the iteration stable and makes the backlog, not the iteration, the place where change is absorbed. When someone outside the team pushes for a new request to start straight away, the agile practitioner connects them with the product owner, who owns the order and can place the request so it starts at the next planning session. The decision then rests with the person accountable for value, and the team keeps its focus.

The exception is an iteration whose goal has become obsolete. If the partner a goal was built to integrate with ends the partnership, or the problem the goal addressed disappears, finishing the iteration delivers nothing of value. In Scrum, only the product owner can cancel a sprint, and the Scrum Guide says a sprint can be cancelled if its goal becomes obsolete. Any done work can still be reviewed or released, the unfinished work goes back to the backlog, and the team replans around the new priorities. Cancellation is rare and disruptive, so it is reserved for that case.

A done increment is releasable, but whether and when it is actually released is a business decision that belongs to the product owner. The definition of done says the increment is good enough to ship; the product owner weighs whether the business is ready for it, for example whether contract terms or customer communications are ready, whether a business calendar constraint applies or whether a regulator must approve first. Developers, operations and other stakeholders advise on readiness; the product owner makes the call.

Two opposite mistakes show up in practice:

• Holding back done increments for a "big bang". Waiting for everything before releasing anything delays value that already exists. Each done increment that would help users if released is value lost for every iteration it waits, and real feedback is postponed with it. Agile release planning favours releasing value as soon as it is done and useful.
• Treating a fixed launch date as a reason for no feedback. Sometimes a general release genuinely has to wait, for a contractual go-live or a regulatory switch-over. A constraint on general availability is not a constraint on all exposure: limited releases such as an internal beta, an opt-in group, feature flags for a few accounts or running the new function alongside the old one on real data all put working product in front of real users. Early, real feedback continues without breaking the launch constraint.

Release planning ties these together. A release plan groups increments toward a meaningful release, often a minimum viable product or minimum marketable feature first, and is revisited every iteration as velocity, scope and priorities change. How the roadmap and release plan are built is covered in backlog refinement; for increments, the point is that every done increment is a release option the product owner can exercise.

An increment goal (an iteration or sprint goal) is a single, coherent objective that states what the increment will achieve and why it matters, such as "library members can renew a loan from the catalogue page". It is agreed at iteration planning, and the selected backlog items are the team's current plan for reaching it. The goal is the commitment; the selected stories are the forecast.

A good increment goal has these traits:

• It states an outcome, not a list of work. "Complete the nine selected stories" is a list. It gives no way to decide which story to drop when time runs short, and it turns any slipped story into a "failed" iteration. An outcome such as "drivers can log a delivery exception from the van" tells everyone what matters and what can flex.
• It fits one iteration. A goal that the developers estimate needs several iterations may be a fine release objective, but it is not an iteration goal. A good goal is a meaningful step toward the larger aim that the team believes it can reach in this timebox; ambition is not a reason to plan work the team cannot finish.
• It is shared. The product owner proposes how the increment could add the most value, and the whole team, product owner and developers together, shapes and agrees the goal at planning. A goal imposed on developers who were never asked tends to be one they do not believe in. When a goal reaches planning already fixed, the agile practitioner's role is facilitation: helping the product owner and developers shape the goal together, so the product owner keeps ownership of value and the developers can commit to it.
• It gives the work coherence. The selected items should combine to achieve the goal, rather than being unrelated tasks bundled into the same two weeks.

In Scrum the sprint goal is formally part of the sprint backlog and created at sprint planning; in other frameworks the same idea appears as an iteration objective or, in SAFe, iteration goals and PI objectives. The principle the exam tests is framework-neutral: each increment should have one clear purpose that the team owns.

Holding the goal while the scope flexes

During the iteration, the goal and the timebox stay fixed while the detailed scope is renegotiated with the product owner as the team learns more. This is what makes the goal useful: when a story turns out much larger than estimated, or a dependency blocks part of the work, the team asks which scope still achieves the goal; the timebox and the quality bar are not the variables.

Typical moves include delivering a basic path of a story now and the refinements later, deferring a supporting feature (for example, an export option) when the core outcome can still be reached without it, and splitting a story so the part that serves the goal finishes this iteration. Each of these is a conversation between the developers and the product owner, who decides what matters most to the goal and the business. The developers do not cut scope on their own, and the product owner does not insist on every original story regardless of what has been learned.

The goal should not be rewritten mid-iteration just to match whatever is finishing. A goal is an outcome, so deferring a supporting item that the outcome does not depend on leaves the goal intact; the deferred item simply returns to the backlog to be ordered for a later increment. If the goal itself can no longer be met in any meaningful form, that is the moment to make it visible to the product owner and stakeholders early, not at the review.

The definition of done is the shared quality standard that every backlog item, and so every increment, must meet before it counts as complete. A typical definition of done includes items such as code peer-reviewed, automated tests written and passing, integrated in the main branch, security scan run, and user help updated. Acceptance criteria, by contrast, are the specific conditions a single story must satisfy to do what its user needs, often written in a given-when-then form.

An item is done only when it meets both: its own acceptance criteria and the definition of done. Product owner approval of the behaviour does not make an item done while any part of the definition of done is still outstanding. Acceptance criteria can add conditions on top of the definition of done; they never subtract from it. Exempting a category of items from part of the definition of done lowers the shared quality bar and makes "done" mean different things for different items; any change to the standard is a team decision about the definition itself, and raising it is far more common than lowering it.

The definition of done also governs what is demonstrated. Only done work is shown as part of the increment. Work that fails the definition of done, however close it is and however keen stakeholders are to see it, goes back to the product backlog; presenting it as complete misleads stakeholders about what they actually have. At most it can be mentioned honestly as not yet done.

Teams raise their definition of done as they learn. When defects keep coming from one recurring cause, such as configuration changes deployed without review, adding a check for it to the definition of done is a normal retrospective outcome. Once added, it applies to every item, and the team plans future iterations with the extra work in mind, accepting slightly less new scope in exchange for fewer defects. When several teams build one product into one combined increment, they should share one definition of done that covers integration, and integrate and test their work continuously during the iteration rather than at the end, so that features each team called complete actually work together.

The iteration review (sprint review, or demo) is a working session in which the team shows the working increment to stakeholders so their feedback can shape what comes next. Its purpose is learning, not approval: the Scrum Guide describes the sprint review as a working session and says the team should avoid limiting it to a presentation. It is not a status meeting, a slide deck of completed story titles, or a formal sign-off ceremony.

Reviews that produce useful feedback share some traits:

• People use the real thing. Stakeholders try the working increment, ideally on realistic data, rather than watching slides or a velocity chart. Work with little visible change, such as faster calculations or more accurate results behind the same screens, can still be demonstrated by letting stakeholders exercise it with their own cases and judge the difference for themselves.
• The conversation looks forward. Asking what should change in the coming increments, what surprised people and what they would do next turns the session into input for the backlog.
• The right people attend (see below).
• Every increment is demonstrable. That depends on how the work is sliced (see the section on vertical slices).

Demonstrating every iteration is what makes feedback early. Showing nothing until a product is "complete" means discovering misunderstandings when they are most expensive to fix. A demonstration after each increment means discovering them while the next increment can still change course.

Who to invite and what to do with feedback

The people to invite to a demonstration are the people whose feedback can change the product: actual users, customer representatives and the stakeholders whose goals the product serves, not only the managers who fund it. Sponsors and department heads can approve features, but they often do not use the product every day. When reviews are attended only by the people who fund or manage a product, problems that only daily users would notice surface after release instead of at the review. So the audience should include representatives of each group whose work the increment changes, even when that makes the session a little longer.

Feedback from a demonstration goes into the product backlog, and the product owner orders it by value like any other work. This holds however small a request looks. Agreeing on the spot to build a request, however small, bypasses the product owner's ordering and changes an iteration plan agreed around a different goal. Capturing it as a backlog item keeps the decision with the person accountable for value. Separate requests are captured as separate items, so each can be ordered on its own merit, and then ranked against existing items by value rather than automatically going to the top because they are new.

Feedback often conflicts. For example, a regional manager may want an extra approval step that frontline staff say will slow every order. Neither the requester's rank nor a compromise that half-satisfies both settles it. The product owner weighs both requests against the product goal (for example, faster order turnaround) and orders the backlog accordingly, often with more evidence from the users the goal depends on.

A team can demonstrate value every iteration only if it slices work vertically: each story cuts through all the layers needed, such as user interface, services and data, to deliver a small piece of working capability end to end. Building horizontally, the database layer in one iteration, the services in the next and the interface after that, produces increments that nobody outside the team can use or judge, and so delays all real feedback until the last layer lands.

A useful first slice answers the stakeholders' biggest question with working product. If stakeholders' main doubt is whether a new capability will work with their real data, a simple version running on that data is a better first increment than a more polished internal component they cannot judge.

Sometimes a release truly cannot happen until a large piece is complete, for example when a new billing engine cannot replace the old one until every tariff is supported. The team still delivers working slices each iteration and gathers evidence by running them alongside the existing system on real inputs and comparing the results. Being unable to release is not a reason to stop demonstrating working product. Techniques for splitting stories themselves (by workflow step, business rule, data variation and so on) are covered in the backlog refinement lesson.

The delivery of value is measured by outcomes tied to the business goal the product was funded for, not by output measures of how much the team built. Velocity, story points completed and features shipped describe effort and capacity; they say nothing about whether customers are better off. A team can raise its velocity sharply while what it releases goes largely unused; that is more output, not more value.

Good value measures move with the outcome the product exists to achieve. If a city's permit portal exists to cut phone enquiries, a good measure is calls per hundred applications after each release. If a hotel's app aims at shorter check-in queues, the measures are the minutes from arrival to room key and the share of guests who check in on their phones.

Some outcomes lag. Annual membership renewals, for example, only show up a year later, too late to steer two-week increments. The answer is a leading indicator that moves early and predicts the same outcome, such as the share of new members who use the service several times in their first month, tracked alongside the lagging measure. Falling back on velocity because the real outcome is slow is the wrong move: it measures the team, not the value.

When output rises but outcomes do not, the product owner reviews the usage and outcome data with stakeholders and reorders the backlog toward what moves the outcome. Pushing the team for more speed only produces more of what is not being used. Defining the product's overall success criteria and confirming that targeted business results are achieved is covered in the Manage value delivery lesson; this section is about reading value increment by increment.

A value burnup chart shows, iteration by iteration, the cumulative business value delivered against the total value planned for the release. Each backlog item carries a relative business value estimate (business value points, assigned by the product owner and stakeholders), and as items are done their value points are added to the line. Plotting value rather than story points shows stakeholders how much of what the release is worth has been delivered so far.

The shape of the value curve informs release and stop decisions. Because the backlog is ordered by value, the most valuable items come first and the value curve normally rises steeply early and flattens later. A flattening value line while the effort line keeps its pace does not mean the team has slowed; it means each further item adds little. That is the signal for the product owner and stakeholders to weigh the remaining value against the remaining cost, because further spending buys diminishing returns.

The ordinary burn charts also matter when reading delivery:

This is why a burnup is the clearer chart whenever scope is changing: it separates the question "is the team delivering?" from "is the target moving?" How teams keep charts like these current and visible is covered in the Visualize work lesson.

Agile earned value: SPI and CPI

Agile earned value management (agile EVM) applies earned value ideas to a release by using story points to measure progress. It compares the percent of the release's planned scope actually completed with the percent the plan expected by now, and with the money spent. It works best for a release with a reasonably fixed budget and scope, which is why it appears most in the measurement of value delivery against a funded plan.

• Planned percent complete = the share of the release the plan expected to be complete by now (often iterations completed divided by iterations planned, or planned points by now divided by total points).
• Actual percent complete = story points completed divided by total planned story points for the release.
• Planned value (PV) = planned percent complete x budget at completion (BAC).
• Earned value (EV) = actual percent complete x BAC.
• Schedule performance index (SPI) = EV / PV, which simplifies to actual percent complete / planned percent complete.
• Cost performance index (CPI) = EV / actual cost (AC).

Worked example: a release has a budget of $500,000 for 250 story points. The plan expected 100 points (40%) to be complete by now; the team has completed 80 points (32%), and actual cost is $150,000. EV = 32% x $500,000 = $160,000; PV = 40% x $500,000 = $200,000. SPI = 160,000 / 200,000 = 0.80 (behind schedule). CPI = 160,000 / 150,000 = about 1.07 (under budget for the work done).

Reading the indexes is the same for both: above 1 is favourable, below 1 is unfavourable. So an SPI of 0.95 with a CPI of 1.20 means the release is slightly behind schedule but getting more work done per dollar than planned. Agile EVM depends on the total scope in points staying meaningful, so when scope changes the baseline is re-planned. It measures progress against plan; it does not by itself show whether the delivered work is valuable, which is why it sits beside outcome measures and value burnups rather than replacing them.