PMP People — Leading Projects 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.

• ✗

  Ask the team to work overtime to compensate for lost velocity

  Why it's wrong here

  Asking the team to work overtime treats a symptom—lost velocity—rather than the root causes of unclear requirements and frequent interruptions. In agile frameworks, overtime is a short-term capacity increase that does not improve requirement clarity or reduce workflow disruptions; it typically accelerates burnout and further degrades velocity. This option is tempting because overtime can temporarily boost output when a fixed deadline is at risk and the backlog is well-defined, making it a plausible corrective action for a pure capacity shortfall.

• ✗

  Add more team members to the next sprint to increase capacity

  Why it's wrong here

  Adding team members to a struggling agile team, especially mid-project or sprint, often invokes Brooks's Law, where "adding manpower to a late software project makes it later." New members require onboarding, training, and integration into existing team dynamics, which diverts effort from current team members and initially reduces overall productivity and velocity rather than increasing it. This action fails to address underlying issues like unclear requirements or interruptions, which are more likely causes of declining velocity.

• ✓

  Work with the product owner to improve user story refinement and ensure acceptance criteria are clear

  Why this is correct

  Declining sprint velocity often stems from ambiguity in work items, leading to rework, delays, and scope creep within a sprint. Collaborating with the Product Owner to enhance user story refinement ensures that backlog items are "ready" for development, meaning they are clear, concise, and have well-defined, testable acceptance criteria. This proactive approach minimizes mid-sprint clarifications and re-estimation, thereby stabilizing and improving the team's ability to consistently deliver value and maintain predictable velocity.

• ✓

  Establish a policy to shield the team from interruptions during the sprint

  Why this is correct

  Frequent interruptions, such as ad-hoc requests, urgent bug fixes not part of the sprint backlog, or excessive meetings, force team members into costly context switching. This fragmentation of focus significantly degrades productivity and flow, directly impacting the team's ability to complete committed work and maintain consistent velocity. Implementing a policy to shield the team creates dedicated focus time, allowing them to concentrate on sprint goals and deliver value more efficiently.

• ✗

  Reduce the sprint length to increase accountability

  Why it's wrong here

  Reducing sprint length, while potentially increasing the frequency of feedback loops, does not inherently improve accountability or address the root causes of declining velocity, such as unclear requirements or external interruptions. Shorter sprints can actually intensify pressure, reduce the time available for complex tasks, and increase overhead from more frequent sprint ceremonies, potentially further destabilizing velocity rather than improving it. Accountability is better fostered through transparent progress, clear commitments, and regular retrospectives, not merely by shortening the iteration cycle.

Go deeper

Related to this question