1.
Determine how to plan project iterations
Planning project iterations means breaking the project into short, repeatable cycles
(iterations/sprints) that each deliver measurable value.
Key steps:
Start with high-level scope (vision, goals, WBS).
Prioritize work based on value, risk, and dependencies.
Define a fixed iteration length (e.g., 1–4 weeks).
Plan only the next iteration in detail; keep later iterations at a higher level.
Review outcomes at the end of each iteration and adjust plans based on feedback.
The goal is to balance predictability with flexibility.
2. Distinguish the logical units of iterations
Logical units are the chunks of work that make sense to deliver and review together.
Common logical units include:
Features or user stories (customer-facing value)
Functional components (e.g., login module, reporting engine)
Risk-driven work (proofs of concept, technical spikes)
Lifecycle stages (design → build → test → integrate)
Good iteration units:
Are small enough to complete within one iteration
Produce something testable or reviewable
Reduce risk or uncertainty
3. Interpret the pros and cons of iteration
Pros
Early and frequent delivery of value
Faster feedback from stakeholders
Better risk management (problems surface sooner)
Easier to adapt to changing requirements
Improves team learning and quality over time
Cons
Requires strong stakeholder engagement
Less upfront predictability than fully predictive plans
Poorly defined iterations can cause scope creep
Needs disciplined prioritization and backlog management
4. Translate this WBS to an adaptive iteration
To translate a Work Breakdown Structure (WBS) into adaptive iterations:
1. Decompose WBS work packages into smaller, value-focused items.
2. Convert work packages into:
o User stories
o Features
o Tasks aligned to outcomes
3. Prioritize items by value, risk, and dependencies.
4. Group the highest-priority items into the first iteration.
5. Leave lower-priority WBS elements loosely planned for later iterations.
Instead of executing the WBS strictly top-down, you pull work incrementally based on
learning and feedback.
5. Determine inputs for scope
Key inputs for defining and refining scope include:
Business case and project charter
Stakeholder needs and expectations
WBS and scope baseline
Product backlog or requirements list
Constraints (time, cost, regulatory)
Lessons learned from prior iterations
Feedback from reviews and retrospectives
In adaptive approaches, scope is progressively elaborated, not fixed upfront.
6. Explain the importance of adaptive project tracking versus predictive, plan-based
tracking
Predictive (plan-based) tracking
Tracks progress against a fixed baseline plan
Uses milestones, earned value, and schedule variance
Works best when requirements are stable
Adaptive project tracking
Tracks value delivered, not just tasks completed
Uses velocity, burn-down/burn-up charts, and completed features
Continuously re-prioritizes based on feedback and change
Why adaptive tracking is important
Reflects real progress, not just planned progress
Supports changing requirements and uncertainty
Enables faster decision-making
Focuses on outcomes rather than compliance with an outdated plan
In complex or uncertain environments, adaptive tracking provides more accurate and
actionable control than rigid plan-based tracking.