PMP · Question #841
During the execution phase, the project manager discovered that the deliverables are not meeting the quality specifications requested by the main stakeholder. This has caused the schedule performance
The correct answer is B. Reinforce the definition of done (DoD) during sprint planning so that the team has a common. The project is experiencing quality issues leading to rework and negative performance indices, so the project manager should reinforce the Definition of Done to ensure the team understands and meets quality expectations for future deliverables.
Question
During the execution phase, the project manager discovered that the deliverables are not meeting the quality specifications requested by the main stakeholder. This has caused the schedule performance index (SPI) to deteriorate from 0.98 to 0.72 and the cost performance index (CPI) from 1.5 to 1.1. What action should the project manager take to mitigate the issue of the deliverables being rejected during the next iteration?
Options
- ASubmit a change request to prioritize resolutions for the quality issue to minimize the impact on
- BReinforce the definition of done (DoD) during sprint planning so that the team has a common
- CCreate a dedicated sprint to complete all of the pending specifications from previous sprints.
- DAssure that the product backlog is properly prioritized to avoid dependencies that cause rejection.
How the community answered
(32 responses)- A6% (2)
- B56% (18)
- C13% (4)
- D25% (8)
Why each option
The project is experiencing quality issues leading to rework and negative performance indices, so the project manager should reinforce the Definition of Done to ensure the team understands and meets quality expectations for future deliverables.
Submitting a change request might address the current issue but doesn't prevent future quality issues if the team's understanding of "done" is misaligned with stakeholder expectations.
Reinforcing the Definition of Done (DoD) during sprint planning ensures that the team has a clear, shared understanding of what constitutes a complete and acceptable deliverable, thereby preventing future rejections due to unmet quality specifications. This proactive measure focuses on improving the quality of work upfront rather than reacting to rejected deliverables.
Creating a dedicated sprint for pending specifications is a reactive measure that adds to the schedule and cost without addressing the root cause of quality issues for new deliverables.
While a properly prioritized product backlog is important, it primarily addresses the order of work, not the quality of the work being produced for each item.
Concept tested: Quality management in agile projects
Source: https://www.pmi.org/pmbok-guide-standards/foundational/agile-practice-guide
Topics
Community Discussion
8
Mateus R.Dec 20, 2025B is the answer. Think of it like a bakery where the bread keeps coming out underbaked: you don't schedule a special week just to re-bake loaves, you post the recipe and temperature rules on the wall so every baker follows the same standard from now on. Reinforcing the definition of done during sprint planning ensures the team shares a common, clear quality bar before work begins, which prevents those rejected deliverables in the next iteration rather than just chasing fixes after the fact.
Orla P.Dec 29, 2025Leaned toward A first but next iteration means fix the DoD in sprint planning, so B.
Nina C.Jan 6, 2026Going with C here. With SPI dropping to 0.72 and quality rejections piling up, a dedicated sprint to clear the backlog of unfinished specs is the most direct way to stop the bleeding before the next iteration.
Mateus R.Jan 8, 2026Nina, I'd flip to B here. Going on a spec-writing sprint while quality is tanking is like fixing the recipe card while the kitchen is on fire. B is the right call because when defects are piling up and your schedule performance is underwater, you halt new work and run a stabilization sprint to root out the quality issues, otherwise you are just accumulating more buggy work on top of an already broken foundation.
Carlos M.Dec 13, 2025Going with D. The root cause here is backlog prioritization letting dependencies slip through and cause rejections, so fixing that prevents the same mess next iteration instead of just patching symptoms.
Orla P.Dec 15, 2025B is correct here because the issue is a late-breaking discovery of a dependency, not a backlog prioritization problem. Adding a dependency check to the definition of ready catches these before work starts, which is exactly what D would not fix since slipped dependencies are a symptom of missing upfront validation, not a symptom of prioritization choice.
Hiroshi T.Dec 26, 2025Going with C here. The SPI cratering from 0.98 to 0.72 tells you rework is piling up and the team is bleeding time on rejected deliverables, so a dedicated sprint to clear the backlog of pending specs is the most direct corrective action. A and B are preventative measures that help future iterations but do not address the accumulated quality debt dragging the indices down right now. D is backlog hygiene, which matters, but it does not resolve the technical debt already on the board. You need to stop the bleeding before tuning the process.
Mateus R.Dec 27, 2025Hiroshi, the SPI drop actually points to inaccurate estimating, not quality rework, so the fix is B, refining the estimation process so future sprints reflect reality. A spec-clearing sprint treats the symptom without fixing why every estimate keeps missing.