PMP Process — Managing Technical Aspects 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.

• ✗

  Add more team members to the project to increase capacity

  Why it's wrong here

  This option often leads to "Brooks's Law" in software development, where adding more people to a late project makes it later. New team members require onboarding, training, and integration into existing team dynamics, which consumes the time of existing members and initially reduces, rather than increases, overall velocity. Furthermore, it fails to address the root cause of the velocity drop, which is often process-related or due to external factors like unplanned work, not a simple lack of hands.

• ✗

  Reduce the sprint backlog size to lower the team's workload

  Why it's wrong here

  While reducing the sprint backlog might seem to alleviate immediate pressure, it's a reactive measure that doesn't address the underlying cause of the velocity drop, especially if unplanned work is the primary culprit. Simply lowering the workload without understanding why the current workload isn't being completed effectively will likely lead to a recurrence of the problem in subsequent sprints. The team's capacity is being consumed by something else, and merely reducing planned work doesn't eliminate that 'something else' or improve predictability.

• ✓

  Analyze the sources of unplanned work and discuss with the team how to minimize interruptions

  Why this is correct

  A drop in velocity, particularly when linked to unplanned work, signals a systemic issue that requires root cause analysis rather than superficial adjustments. This option directly addresses the problem by investigating why unplanned work is occurring and empowering the team to devise strategies to mitigate these interruptions. This proactive, team-centric approach aligns with agile principles of continuous improvement and problem-solving, ensuring sustainable velocity rather than just temporary fixes.

• ✗

  Ask the product owner to prioritize all unplanned work into upcoming sprints

  Why it's wrong here

  Prioritizing unplanned work acknowledges its existence but fundamentally shifts the problem rather than solving it. While the Product Owner is responsible for backlog prioritization, simply adding unplanned work to the backlog doesn't eliminate its disruptive nature or prevent future occurrences. This approach fails to address the root causes of the unplanned work, such as technical debt, poor requirements, or external dependencies, which will continue to erode velocity and team morale.

Go deeper

Related to this question