4.2. Planning Project Iterations

💡 First Principle: Adaptive planning isn't the absence of planning — it's planning broken into short, repeatable cycles, where each cycle's plan is informed by what was learned in the last one. "No upfront plan" and "plan every iteration instead of once" are very different claims, and the exam tests the second one.

Logical units of iteration. An iteration (commonly a sprint) is a fixed-length timebox — often one to four weeks — during which a defined slice of work is planned, built, and reviewed. Shorter iterations mean faster feedback but more planning overhead; longer iterations reduce overhead but slow the feedback loop that makes adaptive valuable in the first place. Choosing iteration length is itself a trade-off decision the exam expects you to reason through, not a fixed rule.

From WBS to adaptive iteration. A work breakdown structure decomposes total project scope into manageable pieces (full detail in Phase 5). In an adaptive project, that same decomposition instinct applies — but instead of assigning pieces to a fixed schedule, scope gets broken into backlog items sized to fit inside a single iteration. The skill being tested is translation: taking a larger piece of scope and right-sizing it so a team can realistically finish it within one timebox.

Determining scope inputs. Iteration scope is pulled from a prioritized product backlog, informed by stakeholder value ranking and what the team learned in the previous iteration — not decided independently by the team without reference to backlog priority.

Why adaptive tracking differs from predictive tracking. Predictive tracking measures progress against a fixed baseline (percent complete against the original plan). Adaptive tracking measures progress by what's actually been delivered and accepted each iteration — a burndown of remaining backlog work, not a percentage against a plan that was never meant to be fixed in the first place.

⚠️ Exam Trap: "The team skipped planning and just started building" describes a team doing adaptive work badly, not a correct description of how adaptive approaches work. Every iteration still opens with a planning step — it's just scoped to that iteration instead of the whole project.

Reading a burndown chart alongside a burnup chart. A burndown chart tracks remaining work shrinking toward zero — useful, but it only tells half the story. If total scope grows mid-iteration because a stakeholder adds urgent new items, a burndown chart alone can look perfectly steady while hiding that growth entirely, since it only shows what's left, not what the total ever was. A burnup chart adds a second line tracking total scope alongside completed work, making scope growth visible the moment it happens. A scenario where a team's burndown "looks fine" but stakeholders are still surprised by how much work remains is often pointing at exactly this blind spot — the fix isn't distrusting the burndown chart, it's pairing it with a burnup, since the two charts together give a genuinely complete picture that neither one provides on its own.