Courseiva
Process — Managing Technical AspectsmediumMultiple ChoiceObjective-mapped

PMP Process — Managing Technical Aspects Practice Question

Your agile team has noticed that sprint velocity has dropped from 30 to 20 story points over the last three sprints. During the retrospective, team members mention unclear requirements and frequent interruptions. As the project manager, what should you do first?

⚠ Common exam trap

A common mix-up: candidates choose to 'accept the lower velocity' (Option D) as a quick fix, mistaking it for empirical process control, when the PMP exam expects you to first investigate and address the root cause of the performance drop rather than merely adjusting the metric.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Work with the product owner to improve user story refinement and establish a 'definition of ready' to reduce ambiguity

The root cause of the velocity drop is unclear requirements and interruptions. By working with the product owner to improve user story refinement and establish a 'definition of ready', you directly address ambiguity before stories enter the sprint, which reduces rework and interruptions. This aligns with agile principles of continuous improvement and focuses on process adjustment rather than superficial capacity changes.

Answer analysis

Option-by-option breakdown

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

  • Work with the product owner to improve user story refinement and establish a 'definition of ready' to reduce ambiguity

    Why this is correct

    A drop in sprint velocity often indicates impediments related to unclear requirements or poorly defined work items. Improving user story refinement ensures that stories entering the sprint backlog are well-understood, estimated, and meet the 'Definition of Ready' criteria, which typically includes clarity, testability, and appropriate sizing. This proactive approach reduces rework, minimizes mid-sprint clarifications, and allows the team to focus on delivery, thereby restoring or improving velocity.

  • Add more team members to the next sprint to increase capacity

    Why it's wrong here

    Adding more team members to an existing project, especially an agile one experiencing a velocity drop, often invokes Brooks's Law: 'Adding manpower to a late software project makes it later.' New members require significant onboarding, knowledge transfer, and integration into team dynamics, which diverts existing team members' time and initially reduces overall productivity. This approach fails to address the underlying issues causing the velocity drop, such as unclear requirements or technical debt, and can further destabilize the team's performance.

  • Reduce the sprint length to increase focus

    Why it's wrong here

    Reducing sprint length is a significant process change that requires careful consideration and team consensus, as it impacts planning, review, and retrospective cadences. While shorter sprints can theoretically increase focus by reducing the scope of work, they also increase overhead for ceremonies relative to development time and may not resolve the fundamental causes of decreased velocity, such as poorly defined stories or technical impediments. Without addressing the root cause, a shorter sprint might merely compress the existing problems into a tighter timeframe, leading to increased pressure and potential burnout rather than improved output.

  • Ask the team to commit to a lower velocity in the next sprint planning

    Why it's wrong here

    Committing to a lower velocity in the next sprint planning is an acknowledgment of the current performance but does not address the underlying reasons for the velocity drop. Velocity is an outcome metric reflecting the team's sustainable pace, not a target to be arbitrarily adjusted without understanding the root causes of its fluctuation. Simply lowering the commitment without investigating and resolving issues like ambiguous requirements, technical impediments, or external interruptions means the team will continue to struggle with the same problems, potentially leading to ongoing frustration and a failure to improve.

About these practice questions

One of 800 original PMP practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PMP practice question is part of Courseiva's free PMI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PMP exam.