PMP People — Leading Projects Practice Question
Your project team is experiencing low sprint velocity for three consecutive sprints. The team cites unclear requirements and frequent interruptions. Which TWO actions should you take to address this?
⚠ Common exam trap
Test-takers frequently confuse 'adding more people' (Option A) with a quick fix for low velocity, failing to recognize that the team's cited issues are process-related (unclear requirements and interruptions) rather than capacity-related.
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
✓
Implement a policy to minimize interruptions during the sprint
Option C is correct because the team explicitly cites frequent interruptions as a cause of low velocity, so implementing a policy to protect the sprint (e.g., limiting non-sprint work and ad-hoc requests) directly removes that impediment and lets the team focus on committed work. Option E is correct because unclear requirements are the other stated cause, and improving backlog refinement ensures user stories meet a clear Definition of Ready with acceptance criteria before sprint planning, reducing mid-sprint ambiguity and rework. Option A does not belong because adding members mid-project triggers Brooks's Law effects, onboarding overhead, and communication complexity that typically reduce short-term velocity rather than improve it. Option B does not belong because the problem is attributed to process issues (unclear requirements and interruptions), not individual performance, so replacing people is unjustified and destructive to team stability. Option D does not belong because lengthening the sprint merely stretches the same dysfunction over more time and delays feedback; it does not resolve unclear requirements or interruptions.
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 sprint
Why it's wrong here
Adding more team members to an ongoing sprint often decreases productivity initially due to increased communication overhead and the time required for new members to onboard and understand the project context. This phenomenon, known as Brooks's Law, suggests that adding resources to a late software project makes it later, as the existing team must divert effort to training and integration rather than feature development. It rarely provides an immediate solution for low velocity and can disrupt established team dynamics.
- ✗
Replace underperforming team members
Why it's wrong here
Replacing team members is a drastic and demotivating action that should only be considered after extensive coaching, performance management, and root cause analysis have failed. Low sprint velocity is often a systemic issue related to process, environment, or unclear requirements, rather than solely individual underperformance. Such a move can severely damage team morale and trust, potentially exacerbating velocity problems and creating a culture of fear.
- ✓
Implement a policy to minimize interruptions during the sprint
Why this is correct
Implementing a policy to minimize interruptions allows the development team to maintain focus and achieve a "flow state," significantly improving productivity and sprint velocity. Frequent context switching due to unplanned requests or external distractions fragments work time, leading to incomplete tasks and reduced output. Dedicated, uninterrupted work blocks enable the team to concentrate on sprint goals and deliver committed increments more efficiently.
- ✗
Increase the sprint length to give the team more time
Why it's wrong here
Increasing sprint length merely postpones the problem and does not address the underlying causes of low velocity, such as unclear requirements or technical impediments. Agile principles emphasize short, iterative cycles to maximize feedback and adaptability; longer sprints reduce the frequency of inspection and adaptation, delaying value delivery and potentially leading to larger, more complex issues at the sprint review. This approach often masks inefficiencies rather than resolving them.
- ✓
Improve backlog refinement to ensure requirements are clear before the sprint
Why this is correct
Improving backlog refinement ensures that product backlog items meet a "Definition of Ready" before being pulled into a sprint, meaning they are clear, well-understood, and estimated. This proactive approach significantly reduces ambiguity, minimizes mid-sprint clarification needs, and prevents costly rework due to misunderstood requirements. Clear requirements directly contribute to more predictable sprint velocity and higher quality deliverables.
Visual reference
Go deeper
Related to this question
Learn chapter
Leading Teams and Empowering Team Members
Key term
Sprint Planning
Sprint Planning is a time-boxed meeting at the start of a Scrum sprint where the team decides what work they can deliver and how they will do it.
Key term
Scrum Methodology
Scrum is a lightweight process framework that helps teams deliver complex projects in small, iterative chunks called sprints.
About these practice questions
One of 820 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 →
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.