3.5. How Methodology Shapes Business Analysis

💡 First Principle: The BA role doesn't disappear or get replaced depending on methodology — it changes shape. In a predictive project, BA work front-loads into detailed requirements documentation before execution begins. In an adaptive project, BA work continues throughout, refining the backlog iteration by iteration as the team learns more.

⚠️ Exam Trap: Don't assume business analysis is "a predictive-only discipline that agile replaced." The ECO explicitly tests recognizing that BA work exists in both approaches — the difference is timing and artifact, not whether BA happens at all.

A worked example. Two teams each start a new project. Team A spends the first six weeks with a BA running structured interviews and workshops, producing a detailed requirements document and RTM before any development begins — a predictive pattern. Team B has a BA embedded permanently on the team, refining backlog items every sprint based on what the last iteration revealed — an adaptive pattern. Both teams have a BA doing real, substantial work; a scenario that describes Team B's continuous involvement and asks "is business analysis happening here?" is testing whether you recognize adaptive BA work for what it is, rather than expecting it to look like Team A's upfront-heavy model.

Hybrid projects. Many real (and exam) scenarios blend both patterns — a project might front-load high-level requirements the way Team A does, then hand off detailed refinement to an adaptive backlog process the way Team B does for the features still being discovered. The BA's role in a hybrid scenario isn't a strict either/or; it shifts weight between upfront documentation and continuous refinement depending on which parts of the project are well understood versus still evolving. Recognizing that mix — rather than forcing a scenario into a purely predictive or purely adaptive label — is exactly the kind of hybrid thinking flagged as a first-principles idea back in Phase 1.

Allocating limited BA time across a hybrid project. When time is genuinely scarce, a stable set of compliance requirements and a rapidly evolving set of user-facing features don't need equal attention. The stable requirements need real upfront rigor once, then comparatively little ongoing time; the evolving ones need continuous, iteration-by-iteration refinement precisely because they keep changing. A scenario asking how to split limited hours between the two is testing whether you'll match effort to volatility, not split time evenly out of a sense of fairness.

Why a BA's own weighting shifts over a project's lifetime, not just between projects. The predictive/adaptive split isn't fixed at kickoff and frozen there — a piece of scope that started genuinely uncertain can become well understood as the team learns more, and vice versa. A BA who notices their own working rhythm shifting from continuous refinement toward occasional upfront documentation on a given piece of scope isn't drifting off pattern; they're correctly tracking how well-understood that scope has actually become. Recognizing this as a legitimate, expected shift — rather than a sign something has gone wrong — is itself part of the judgment this section is testing.