Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

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. The Definition of Done specifies exactly what "complete" means before work starts — tested, reviewed, documented, whatever the team has agreed constitutes done. In Scrum it applies to the Increment: the moment a Product Backlog item meets the Definition of Done, an Increment exists, and an item that does not meet it cannot be released or even presented at the Sprint Review — it returns to the Product Backlog.

It is distinct from a backlog item's acceptance criteria, which are written for that one item. Without an explicit completion standard, "finished" becomes a matter of opinion, which is exactly the ambiguity adaptive teams eliminate at the delivery 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: The Definition of Done and a backlog item's acceptance criteria sound similar but operate at different levels — the Definition of Done is one team-wide standard applied to every backlog item, while acceptance criteria are written for a single requirement. A scenario asking "what standard applies to every piece of work this team completes" is pointing at the Definition of Done, not acceptance criteria.

⚠️ Exam Trap: There is one Definition of Done per product, not one per work type. Where the organization publishes a Definition of Done, teams must follow it as a minimum (they may strengthen it, never weaken it); where several teams build the same product, all of them must comply with the same one. Options offering per-team or per-task-type standards are testing exactly this.

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 item 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.

See how it connects
Alvin Varughese
Written byAlvin Varughese
Founder20 professional certifications