Ask anyone who's taken the PMI-ACP which questions haunted them, and you'll hear a version of the same scenario: the team is failing — missed sprint goals, conflict in the retro, a stakeholder losing patience — and you, the agile leader, must choose what to do. Every answer option sounds plausible. Two feel responsible. One is right. Let's break down why, because this question family is worth a lot of points.

Why these questions are hard on purpose

When a team struggles, every instinct we learned in traditional management says: step in, take charge, fix it. The exam is specifically testing whether you've replaced that instinct. A servant leader's job in a failing moment is to help the team see the problem, own the problem, and solve the problem — not to solve it for them. The wrong answers are almost always competent-sounding versions of taking over.

The answer pattern (learn this and the family opens up)

When the scenario says the team is failing, rank your moves in this order:

  • 1. Make the problem visible to the team. Bring data to the retrospective, ask open questions, surface the issue where the team can see it.
  • 2. Facilitate the team's own diagnosis. The team names root causes; you hold the space. Answers with the words "facilitate," "coach," or "ask the team" deserve a long look.
  • 3. Remove impediments the team can't remove. If the blocker is outside their control — an absent product owner, an org-level dependency — that's your lane. Act on it.
  • 4. Escalate or restructure, last. Only after the team has genuinely tried and the impediment outranks you.

And the standing traps: don't reassign work yourself, don't extend the sprint to hide the miss, don't report individuals to management, and don't quietly absorb the problem to protect the team from the truth. Each of those shows up as a tempting option, dressed in reasonable language.

A worked example

Your team has missed its sprint goal three sprints running. In the retrospective, members blame each other and the product owner for unclear stories. A senior stakeholder asks you to "sort the team out." What should you do first?

Option A: meet privately with the weakest performer. Option B: facilitate a root-cause session where the team examines the three sprints together. Option C: escalate the unclear-requirements problem to the product owner's manager. Option D: commit the team to a recovery plan you design.

It's B — and now you can say precisely why. A treats a system problem as a person problem. D is command-and-control in a friendly costume. C escalates before the team and product owner have even talked properly. B makes the problem visible and lets the team own the diagnosis. First move, every time: turn the team toward the problem, not yourself.

Turning the pattern into points

One worked example won't make this automatic — the exam will re-skin this scenario a dozen ways (failing velocity, feuding developers, a hero developer burning out, a stakeholder bypassing the process). The pattern holds across all of them, but only if you've drilled it enough to recognize the costume changes.

That's exactly how our scenario-based PMI-ACP practice exam is built: failing-team scenarios in every variation, with explanations that name the principle behind the right answer and the trap behind each wrong one. Work through enough of them and exam day stops feeling like a judgment test and starts feeling like recognition. Which, honestly, is what good agile leadership feels like too.