Agile business analysis principles and mindset
Domain 1 tests whether you can recognise and apply the mindset that distinguishes agile business analysis from a phase-gated approach: value-first, collaborative, iterative, and still disciplined. Questions often ask what a BA should do when pressure arises for comprehensive upfront specification.
Core rules
- Analyse continuously, not in a single phase. Plan progressively (rolling wave) and elaborate detail at the last responsible moment.
- 'Working software over comprehensive documentation' means fit-for-purpose artefacts-product vision, context models, decision logs, acceptance criteria-not zero documentation.
- Focus every item on business need and measurable value. If it cannot be traced to an outcome, challenge it.
- Collaborate as a whole team; the BA facilitates shared understanding rather than acting as a scribe or gatekeeper.
- Build incrementally from firm foundations: enough upfront understanding of scope, stakeholders, constraints, and quality attributes to start safely.
- Embrace change with control: visible backlogs, explicit assumptions, decision logs, and re-prioritisation.
- Timebox analysis and satisfice-good enough now, refined later-without compromising quality.
- Deliver on time by managing contingency and keeping Must scope genuinely minimal.
Worked example
A sponsor demands a 60-page requirements specification before funding a new customer portal. The BA proposes a one-page product vision, a context diagram, a MoSCoW-ranked epic list, key non-functional constraints, and a decision log; detailed stories follow per iteration. Reasoning: the sponsor's real need is confidence and governance, not volume. The artefacts answer funding questions while keeping detail deferrable; the decision log and review points preserve control. Producing the full specification would create waste and premature commitment.
Traps that cost marks
- Believing agile means no documentation; the exam rewards 'just enough'.
- Doing all analysis upfront 'to be safe', then defending it as agile.
- Treating the BA as a proxy Product Owner or scribe.
- Modelling for completeness rather than to answer a decision.
- Confusing iterative delivery with lack of discipline or no baselines.