Adaptive delivery fixes the cadence and lets the scope move. Work is done in short cycles of a constant length, each one producing something a stakeholder can look at and react to, and what goes into the next cycle is decided using what the last one taught. The plan is remade continuously at a small scale rather than once at a large one.
That single inversion is what most scenario questions turn on. 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.
Iterating and incrementing are different moves
Iterating means going over the same deliverable repeatedly, each pass improving it. A user interface redesigned four times is iterating, and after three of those passes there may still be nothing anybody can use.
Incrementing means completing pieces in sequence, each one finished and usable when it lands. A building delivered floor by floor is incrementing, and each floor works whether or not the next one 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 exam tends to probe the distinction through consequences, so a question about a stakeholder who cannot use anything for four months is describing an iterative arrangement whatever it calls itself.
Why the timebox holds
A timebox is a fixed duration that does not move. The instinct when work is nearly finished is to add three days, and the reason to refuse is that the cadence is doing three jobs at once.
It produces feedback on a schedule, which is the whole value of the approach. It converts estimating error into information, because work that did not fit tells you something about the estimate that work extended to fit would have concealed. It also makes the next planning session possible, since a session that starts when the last cycle happens to end cannot be a rhythm anybody plans around.
Scope is the release valve. Where a cycle will not hold everything planned, what comes out is the least valuable item rather than the last few days.
The events, and the job each one does
| 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 |
The review and the retrospective are the pair most often confused. The review inspects the product and involves stakeholders. The retrospective inspects the way of working and belongs to the team. Merging them produces a session where the team will not raise process problems in front of the customer, and the process problems are the ones that compound.
Planning at more than one horizon
Nothing about a fixed cadence means the project has no long range plan. What changes is how much detail each horizon carries.
The near horizon is planned in detail because it is about to be built. The middle horizon holds an ordered set of intentions with rough sizes. The far horizon holds themes and a direction. Detail is added as work approaches, which is the same idea as rolling wave planning in a predictive schedule, applied continuously rather than at phase boundaries.
This is what lets an adaptive project answer a question about next March honestly. The answer is a range with a confidence attached rather than a date with a false precision, and it comes from observed delivery rate rather than from a plan written before anything was known.
Done has to mean something
A cycle producing something usable only works if usable is defined in advance and applied uniformly. Without that, work is reported complete and then found to need testing, documentation or integration, and the increment that looked finished is a liability rather than an asset.
A shared definition of completeness turns the cadence into a real measurement. An item is either finished by that standard or it is not, there is no partial credit, and the delivery rate that comes out of counting finished items is therefore worth forecasting from. Where completeness is negotiable, every metric downstream of it 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. 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 rather than as competing methods, and the exam is written accordingly. The questions test whether you can reason about cadence, feedback and the fixed variable inversion in a described situation, not whether you can recall a particular framework's vocabulary.