PMP Process — Managing Technical Aspects Practice Question
Your agile team is consistently completing 30 story points per sprint. In the next sprint planning, the product owner wants to commit to 40 points. The team feels this is too ambitious. Which THREE actions should you take?
⚠ Common exam trap
PMP often tests agile principles and the role of the project manager/Scrum Master in facilitating realistic commitments. Candidates may choose to simply accept the product owner's demand or increase sprint length, but the correct approach is to use data and team empowerment to negotiate a realistic goal. The trap is thinking that the product owner's wish must be followed without question.
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
✓
Suggest decomposing larger stories into smaller ones to improve estimation accuracy
Option B is correct because decomposing large stories into smaller, more granular items improves estimation accuracy and reduces uncertainty, allowing the team to make a more reliable forecast of what fits in a sprint. Option C is correct because agile teams are self-organizing and should transparently push back on commitments they believe are unattainable, rather than accepting an imposed goal that risks burnout and quality erosion. Option D is correct because historical velocity (30 story points per sprint) is the empirical basis for forecasting; reviewing that data supports a realistic, data-driven commitment instead of an arbitrary 40-point target. Option A is wrong because instructing the team to accept an unrealistic goal violates self-management and sustainable pace principles. Option E is wrong because lengthening the sprint to three weeks does not increase the team's throughput capacity and distorts the established cadence rather than addressing the estimation and commitment issue.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Instruct the team to accept the 40-point goal to satisfy the product owner
Why it's wrong here
Instructing the team to accept an externally imposed goal directly contradicts agile principles of self-organizing teams and voluntary commitments. Forcing a commitment undermines team autonomy, erodes psychological safety, and often leads to rushed work, increased technical debt, and decreased team morale, ultimately hindering the delivery of high-quality value and fostering an unsustainable pace.
- ✓
Suggest decomposing larger stories into smaller ones to improve estimation accuracy
Why this is correct
Larger user stories inherently carry greater uncertainty and complexity, making precise estimation challenging. Decomposing these into smaller, more manageable stories reduces the scope of each individual item, clarifies requirements, and often uncovers hidden complexities, thereby significantly improving the precision and reliability of the team's estimates and fostering more accurate sprint planning.
- ✓
Encourage the team to push back if they believe the goal is unattainable
Why this is correct
A fundamental tenet of agile is that the development team, being closest to the work, is best positioned to estimate and commit to what it can realistically achieve. Empowering the team to articulate concerns and push back on unrealistic goals fosters a strong sense of ownership, promotes transparency, and ensures that commitments are based on actual capacity and capability, rather than external pressure.
- ✓
Review historical velocity data to support a realistic commitment
Why this is correct
Velocity, as an empirical measure of the amount of work a team has consistently completed in past sprints, provides objective evidence of their sustainable pace. By analyzing historical velocity trends, the team can establish a data-driven baseline for their capacity, enabling them to make more realistic and defensible commitments for future sprints, rather than relying on subjective assumptions or arbitrary targets.
- ✗
Increase the sprint length to 3 weeks to allow more time
Why it's wrong here
While changing sprint length is a team decision, simply extending the sprint duration does not address the underlying issues of estimation inaccuracy or capacity planning. This approach often masks the problem by providing a temporary buffer, potentially delaying crucial feedback cycles and increasing the risk of scope creep, rather than resolving the root cause of unrealistic commitments or poor estimation practices.
Go deeper
Related to this question
Learn chapter
Planning Project Scope and Requirements
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official PMI exam blueprint
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.