Iterative and incremental delivery are the two moves that adaptive delivery is built from, and the Agile Practice Guide names them as life cycles in their own right alongside predictive and adaptive. An adaptive project fixes its cadence and allows the scope to move. Work proceeds in short cycles of a constant length, each of them producing something a stakeholder may examine and react to, and what goes into the next cycle is decided from what the last one taught. The plan is therefore remade continuously at a small scale, where a predictive plan is made once at a large one.
Most scenario questions turn on that single inversion. In a predictive plan the scope is the commitment and the date is derived from it. Here the date is the commitment, and the scope is what flexes to meet it. The sections below separate the two moves, explain why the timebox holds, describe the events that make the loop work and set out what a usable result has to mean.
How iterating differs from incrementing
Iterating means going over the same deliverable repeatedly, with each pass improving it. Redesigning a user interface four times is iterating, and after three of those passes there may still be nothing anybody can use.
Incrementing means completing pieces in sequence, with each one finished and usable when it lands. Delivering a building floor by floor is incrementing, and each floor works whether or not the next is ever built.
Most adaptive delivery does both. A cycle produces a finished increment and also revisits earlier increments in the light of what has been learned. The examination tends to probe the distinction through consequences. A question about a stakeholder who cannot use anything for four months is describing an iterative arrangement, whatever the question calls it.
Why the timebox holds
Both moves happen inside timeboxes, which are fixed durations that do not move. When work is nearly finished the instinct is to add three days, and the reason to refuse is that the cadence is doing three jobs at once.
The first job is producing feedback on a schedule, and that is the whole value of the approach. The second is converting estimating error into information, since work that did not fit says something about the estimate that work extended to fit would have concealed. The third is making the next planning session possible, because a session beginning whenever the last cycle happens to end is no rhythm anybody can plan around.
Scope is the release valve. Where a cycle will not hold everything planned, what comes out is the least valuable item. The timebox holds.
The four events and the job each one does
Inside the timebox, four events give the cycle its shape.
| Event | Timing | What it decides | What it costs when skipped |
|---|---|---|---|
| Cycle planning | Start of each cycle | What the cycle will attempt and why it is worth attempting | A cycle with no shared objective, where progress cannot be judged because nothing was promised |
| Daily coordination | Each working day, short | What has changed since yesterday and what is now in the way | Blockers that sit for days because the moment to surface them never arrives |
| Review or demonstration | End of each cycle | Whether what was built is what was wanted, judged by somebody able to say | Feedback that arrives at acceptance testing, when changing it is expensive |
| Retrospective | End of each cycle | What the team will change about how it works | A team repeating an inefficiency for the length of the project because nobody owned fixing it |
Of the four, the review and the retrospective are most often confused. A review inspects the product and involves stakeholders. A retrospective inspects the way of working and belongs to the team. Merging the two produces a session in which the team will not raise process problems in front of the customer, and process problems are the ones that compound.
Planning at more than one horizon
Cycle planning covers the next few weeks, and fixing the cadence does not mean the project has no long range plan. What changes is how much detail each horizon carries.
Near work is planned in detail, because it is about to be built. Further out sits an ordered set of intentions with rough sizes attached. Beyond that there are only themes and a direction. Detail is added as work approaches, which is the rolling wave planning of a predictive schedule applied continuously.
This is what allows an adaptive project to answer a question about next March honestly. The answer is a range with a confidence attached, and it derives from the observed delivery rate.
The definition of done
The delivery rate is only worth forecasting from if the items being counted are genuinely finished, and producing something usable at the end of a cycle depends on usable having been defined in advance and applied uniformly. That definition is the definition of done. Without it, work is reported complete and then found to need testing, documentation or integration, and an increment that appeared finished becomes a liability.
Shared completeness turns the cadence into a real measurement. An item is either finished by that standard or it is not, no partial credit exists, and the delivery rate produced by counting finished items is therefore worth forecasting from. Where completeness is negotiable, every metric downstream inherits the ambiguity.
Where each syllabus puts it
Scrum names the cycle a Sprint, fixes it at a month or less and specifies four events with explicit timeboxes. Extreme Programming uses a shorter cycle with an engineering practice set attached to it. Kanban keeps the flow and drops the fixed cycle entirely, replacing cadence with limits on work in progress.
PMI treats all of these as instances of the same life cycle characteristics, and the examination is written accordingly. Questions test whether a candidate can reason about cadence, feedback and the fixed variable inversion within a described situation, and they never test recall of a particular framework's vocabulary.