CAPM Practice: Determine how to document project controls for an adaptive project

The retrospective action list documents specific, actionable improvements (not vague aspirations) with assigned owners and a target completion sprint. It bridges the retrospective discussion to concrete team behavior change. Without documented, tracked actions, retrospectives produce good conversation but little actual improvement. The action list makes continuous improvement systematic.

**Why not A:** Tracking defects found during a sprint is a quality assurance activity captured in the sprint backlog or a defect log, not the retrospective action list. The retrospective focuses on improving team processes, collaboration, and ways of working — not on cataloguing product defects. Mixing defect tracking with process improvement artifacts dilutes the purpose of both.

**Why not B:** A retrospective is a team improvement ceremony, not a personnel grievance mechanism. Documenting complaints for HR review would fundamentally change the psychological safety of the retrospective space, discouraging candor and honest reflection. The retrospective action list is owned by the team and focused on constructive, process-level improvements — not individual grievances or disciplinary concerns.

**Why not C:** Reporting sprint performance metrics to senior management is the function of the Sprint Review or a project status report, not the retrospective. The retrospective is an internal team event focused on introspection and improvement, and its outputs are action items for the team — not dashboards or KPIs for external stakeholders. Conflating these artifacts would compromise the safe, candid nature of retrospective discussions.