CAPM Practice: Determine how project methodologies influence business analysis processes

Traceability in agile uses different tools but serves the same purpose. Stories trace to epics, epics to themes, themes to business goals. Acceptance criteria trace to test cases. Agile tools (Jira, Azure DevOps) support this tracing natively without requiring separate requirements traceability matrices.

**Why not A:** Assigning traceability ownership exclusively to developers misrepresents the BA's role as the bridge between business needs and technical implementation. BAs remain responsible for ensuring requirements are traceable to business goals regardless of who performs the day-to-day tracing. Removing BA accountability would leave a critical gap in requirements governance.

**Why not B:** Agile environments use different artifacts — user stories, backlogs, acceptance criteria — that are fundamentally unlike traditional requirements documents. Applying predictive traceability matrices to agile work creates unnecessary overhead and does not align with how agile teams think about and manage requirements. Effective adaptation means choosing tools that fit the methodology, not forcing old tools into a new context.

**Why not C:** Traceability remains valuable in agile projects; only the mechanisms change. Agile teams still need to understand why a story exists, which business goal it supports, and whether delivered features satisfy the original need. Abandoning traceability entirely would sever the link between business strategy and delivered software.