4.5. Task Management in Adaptive Projects
💡 First Principle: In an adaptive project, "what should we work on next, and how do we know it's actually finished" are answered continuously, at the task level, rather than settled once in an upfront plan.
Interpreting success criteria. A task's success criteria (often captured as a Definition of Done, distinct from a backlog item's individual acceptance criteria) specify exactly what "complete" means before work starts — tested, reviewed, documented, whatever the team has agreed constitutes done. Without explicit success criteria, "finished" becomes a matter of opinion, which is exactly the ambiguity adaptive teams try to eliminate at the task level even while embracing ambiguity at the requirements level.
Prioritizing tasks. Common prioritization approaches rank work by value and effort — highest-value, lowest-effort items typically surface first, with technique names like MoSCoW (Must/Should/Could/Won't) or weighted scoring showing up in more advanced material. For CAPM purposes, the core skill is recognizing that prioritization is an ongoing, value-driven decision each iteration, not a one-time ranking set at project kickoff and never revisited.
⚠️ Exam Trap: A task's Definition of Done and a backlog item's acceptance criteria sound similar but operate at different levels — Definition of Done is a team-wide standard applied to every task, while acceptance criteria are specific to one requirement. A scenario asking "what standard applies to every piece of work this team completes" is pointing at Definition of Done, not acceptance criteria.
A worked prioritization example. A backlog has four candidate items for the next iteration: a high-value feature requiring two weeks of work, a low-value bug fix requiring one hour, a medium-value feature requiring three days, and a high-value feature that's blocked on an external vendor delivery. Ranking purely by value would put both high-value items first — but the blocked item can't actually start yet, so prioritization also has to account for what's currently actionable, not just what scores highest on value alone. This is the kind of judgment call the exam tests: prioritization isn't a single-variable ranking, it's value weighed against what's genuinely ready to be worked on right now.
Why re-prioritization happens every iteration, not once. A backlog item that was low priority two iterations ago can become urgent overnight — a competitor ships a similar feature, or a regulatory deadline moves up. Treating the backlog as a static, one-time-ranked list rather than something revisited each iteration is a common associate-level mistake the exam is designed to catch.
When the two adaptive task-management skills work together. Success criteria and prioritization aren't independent — they're sequential judgment calls applied to the same backlog. Success criteria answer "is this task actually finished," and prioritization answers "what should we work on next." A team that's excellent at defining Definition of Done but never revisits priority order still ships the wrong things well; a team that prioritizes sharply but has no clear completion standard ships the right things poorly. The exam's task-management scenarios often test whether you notice which of the two skills is actually missing in a given breakdown, since the visible symptom — a stalled or disputed backlog item — can trace back to either one, and the correct fix depends on diagnosing which.
