PMP Practice: Execute quality management plan

The root cause is the absence of a clear, shared Definition of Done that establishes what 'complete' means beyond individual story acceptance criteria. In agile environments, acceptance criteria define what a specific user story must do, but the Definition of Done establishes organization-wide or team-wide quality standards that apply to all work—such as code integration, testing protocols, documentation, and defect thresholds. Without this shared understanding established early, the team and product owner had different interpretations of done, leading to stories being marked complete that didn't meet the product owner's quality expectations. The 40% rework rate and integration failures indicate technical practices weren't included in the completion standard. Establishing the Definition of Done during sprint zero or iteration zero, before regular development begins, prevents misalignment by creating explicit, transparent quality gates that everyone commits to. This shared agreement would have prevented stories from being marked done until they met integration and quality standards, eliminating the current quality debt.

**Why not B:** While more detailed acceptance criteria might help with individual story clarity, this doesn't address the systemic quality gap. Acceptance criteria are story-specific; the issue here is the lack of team-wide quality standards that transcend individual stories. The team could meet detailed acceptance criteria and still produce work that doesn't integrate properly or meet quality thresholds. This treats a symptom rather than the root cause—the absence of a Definition of Done that includes technical and integration requirements.

**Why not C:** Code reviews are a valuable quality practice but implementing them reactively doesn't prevent the underlying problem: the team and product owner had no shared agreement on what constitutes done. Code reviews could be part of a Definition of Done, but mandating them alone without establishing comprehensive completion criteria leaves other quality gaps unaddressed, such as integration testing, performance validation, and defect thresholds. This is a tactical solution to a strategic problem.

**Why not D:** Additional retrospectives are reactive—they address problems after they occur. The question asks what should have been done earlier to prevent the quality gap, not how to respond once it emerged. While retrospectives are important for continuous improvement, they wouldn't have prevented the initial misalignment between the team's and product owner's expectations of quality. The Definition of Done needed to be established proactively before stories were completed, not discovered through retrospective analysis of failures.