3.7. Reflection Checkpoint

Key Takeaways

• Process owner, process manager, product manager, and product owner each own a distinct scope — match the described behavior to the definition, not the title's apparent seniority.
• Communication channel choice should match the message's purpose and audience, not default to "more updates is always better."
• Requirements-gathering technique choice (interviews, surveys, workshops, user stories, use cases) depends on the scenario's specific constraint — group size, need for consensus, or complexity.
• An RTM and a product backlog serve the same traceability purpose in predictive and adaptive projects respectively — traceability isn't exclusive to either approach.
• A product roadmap communicates strategic sequencing, not detailed schedule commitments.
• Business analysis work exists in both predictive and adaptive approaches — timing and artifact differ, but the role doesn't disappear in either.
• BA work continues through delivery validation — defining acceptance criteria and confirming the result against the RTM/backlog, not stopping once requirements are gathered.

Connecting Forward

Phase 4 moves into Domain 3 (Agile Frameworks/Methodologies, 20%) — the deepest dive yet into adaptive thinking, covering when adaptive approaches fit an organization, how iterations get planned, what artifacts control an adaptive project, the structural differences between Scrum, XP, SAFe, and Kanban, and how task management works inside an adaptive team.

Self-Check Questions

• A stakeholder tells you "we already know what we want built — just build it and show us at the end." Which requirements-gathering approach does this scenario seem to be steering away from, and what risk does skipping it introduce?
• A team has finished building every item on its product backlog for the release. What one additional BA check is still missing before this work can be considered validated, not just completed?