Study CAPM Impediments, Defects, Technical Debt, and Compliance: key concepts, common traps, and exam decision cues.
Impediments, defects, technical debt, and compliance issues all create pressure on adaptive teams, but they are not the same kind of problem. CAPM often tests whether you can classify the issue correctly before choosing the next response.
An impediment is a blocker affecting work now. A defect is a gap between expected and actual behavior. Technical debt is a quality cost deferred into the future, often in the name of speed. A compliance requirement is a control boundary the team must respect even when it feels inconvenient.
The strongest CAPM answer usually starts by recognizing which signal is present. If the team misclassifies the problem, it often chooses the wrong action.
That classification step is often the whole point of the question. If a team is blocked because an external environment is unavailable, treating that as a normal backlog item misses the fact that delivery is already constrained now. If the problem is a defect, calling it a future enhancement weakens the response. If the team knowingly cut a quality corner, that is not the same thing as a surprise defect. CAPM often tests whether you can choose the control pattern that fits the issue type.
Adaptive delivery is still disciplined delivery. The team can stay flexible without treating control obligations as optional.
| Issue type | What it means | Strong next response |
|---|---|---|
| Impediment | Current blocker to delivery | Surface it, assign ownership, escalate if team authority is insufficient |
| Defect | Delivered behavior does not match expectations | Triage severity, decide treatment timing, correct as needed |
| Technical debt | Deferred quality cost from a shortcut or compromise | Make the tradeoff visible and plan treatment intentionally |
| Compliance requirement | Mandatory governance or control boundary | Build it into the delivery flow early enough to affect decisions |
The exam usually favors visibility and intentional treatment over passive hope. A weak adaptive response is often one that lets the issue stay hidden until it becomes more expensive.
flowchart TD
A["Problem appears"] --> B{"What kind of issue is it?"}
B --> C["Current blocker -> impediment"]
B --> D["Product behavior gap -> defect"]
B --> E["Deferred quality cost -> technical debt"]
B --> F["Required control boundary -> compliance"]
C --> G["Track, assign, escalate if needed"]
D --> H["Assess severity and correct"]
E --> I["Make tradeoff visible and plan treatment"]
F --> J["Integrate control into delivery flow"]
The exam usually rewards responses that make the issue visible and manageable instead of treating it as background noise. It may also test whether compliance belongs only at the end. Usually not. If the control is mandatory, the stronger answer integrates it into the way the team works now.
Technical debt is another common trap. Teams sometimes act as if all debt is harmless as long as they deliver quickly. CAPM usually favors making the debt visible and judging its risk, not pretending speed removed the cost.
CAPM may also test escalation boundaries. If the team has done what it can and the impediment still exceeds its authority, the stronger answer is usually escalation, not endless local workarounds. Adaptive teams are not expected to solve organizational barriers alone when those barriers threaten the iteration goal or release conditions.
A frequent weak answer assumes compliance can be bolted on at the end or that adaptive delivery means governance should be minimized until release. CAPM usually favors the opposite approach: integrate necessary control steps into the flow early enough that they guide real delivery choices.
That might mean:
The point is not to make the method heavy. The point is to keep required control work from becoming a late surprise.
An adaptive team is blocked by a missing test environment, discovers a failed integration behavior in one completed story, and knows it postponed refactoring a fragile component last sprint. At the same time, a regulatory review checkpoint must be completed before release. The stronger interpretation is that the team is handling four different issues that require four different forms of control.
If the team treats all four as generic “stuff in the backlog,” it loses the distinctions that drive the right response. The missing environment threatens current progress. The defect affects delivered behavior. The technical debt affects future quality and speed. The compliance checkpoint constrains release readiness whether the team likes it or not.
Mid-iteration, a team cannot finish a story because a security environment is unavailable. It also discovers that an already-demonstrated feature fails an acceptance rule in one edge case, and it knows a rushed integration shortcut from the prior iteration is becoming harder to maintain. Meanwhile, a mandatory audit trace must exist before release.
The strongest CAPM response is to classify each issue correctly and manage it with the right control pattern: impediment handling and possible escalation for the environment, defect triage for the behavior gap, visible technical-debt treatment planning for the shortcut, and integrated compliance planning for the audit trace.
Scenario: A team cannot finish a high-priority story because an external environment is unavailable. It also finds a defect in a recently demonstrated feature, has postponed cleanup of a fragile integration shortcut for two iterations, and must satisfy a required regulatory check before release.
Question: How should the team classify and handle those issues?
Best answer: B
Explanation: The stronger response recognizes that the scenario contains several different issue types and manages each with the control pattern that fits it.
Why the other options are weaker: