POPM Leadership for PI Planning Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Recommend that the RTE defer all escalated issues to a separate meeting after PI Planning to protect the event schedule.

  Why it's wrong here

  Deferring issues past PI Planning means teams finalize plans with unresolved constraints, which reduces plan reliability and pushes problem-solving into the execution phase where it is more disruptive. The management review and problem-solving session exists precisely so that Business Owners and leadership can address escalated impediments before plans are finalized. Deferring defeats that purpose and undermines the confidence vote.

• ✓

  Help the RTE timebox each escalation, ensure the right decision-makers are present, and capture decisions so teams can adjust plans before final review.

  Why this is correct

  Timeboxing escalations, ensuring decision-makers are present, and capturing decisions keeps the session focused and productive while ensuring teams receive the answers they need to finalize realistic plans. This is a facilitation and flow-management contribution that respects both the event timebox and the need for timely business decisions. It also preserves the session's purpose of resolving impediments before the confidence vote.

• ✗

  Take over the session from the RTE and personally decide all scope trade-offs to accelerate resolution.

  Why it's wrong here

  The Product Manager typically does not own all scope trade-off decisions, especially those involving business priorities that belong to Business Owners. Taking over also undermines the RTE's facilitation role and reduces the session's transparency. Decisions made without the relevant stakeholders present may be reversed later, wasting the time the Product Manager was trying to save.

• ✗

  Ask the teams to resolve the escalated issues among themselves after the session and report back at the next PI Planning.

  Why it's wrong here

  Pushing escalated issues back to teams ignores that these issues were escalated precisely because they require business decisions beyond team authority. Waiting until the next PI Planning leaves the current PI plan built on unresolved constraints and delays value delivery. It also signals that escalation is futile, which discourages teams from raising real impediments in future events.