EXIN BCS Agile BA Professional study materials
EXIN BCS Agile BA Professional study resources

EXIN BCS Agile BA Professional: Agile requirements and backlog management

EXIN BCS Agile BA Professional · Work through your exam, one topic at a time.

All guide sections

Agile requirements and backlog management

Domain 3 covers how requirements are expressed, structured, refined, and prioritised in an agile backlog. The exam tests practical judgement about story quality, slicing, acceptance criteria, non-functional requirements, and prioritisation-not memorised templates.

Backlog structure

Themes group epics; epics decompose into features and user stories; tasks are delivery steps, not requirements. Stories are cards for conversation and confirmation, not mini-specifications. Apply INVEST: independent, negotiable, valuable, estimable, small, testable.

Specification

  • Acceptance criteria define the confirmation; Given/When/Then examples expose rules and edge cases.
  • Non-functional requirements are quality attributes and constraints-capture them explicitly and testably; do not bury them in a story title.
  • Use a Definition of Ready to avoid premature detail and a Definition of Done to prevent partial delivery.
  • Refine just in time; a spike is for learning, not for disguising uncertainty as a story.

Prioritisation

MoSCoW: Must is the minimum usable subset, Should is important but not vital, Could is a nice-to-have, Won't is explicitly out of scope this time. Keep Musts genuinely minimal and protect contingency. Story mapping provides end-to-end slices; vertical slicing delivers value rather than layers.

Worked example

'As a customer I want to search so that I can find products' is too broad. Split by query type-keyword search first, then category filters-and by result action. Acceptance criteria: given a catalogue containing red shoes, when I search 'red shoes', then matching items appear within two seconds. The latency constraint is recorded as an NFR. MoSCoW: keyword search Must; filters Should; saved searches Could. Reasoning: each slice is demoable and valuable; splitting by workflow avoids technical layers.

Traps

  • Writing acceptance criteria as tasks or test steps only.
  • Marking everything Must, leaving no contingency.
  • Omitting NFRs until testing.
  • Confusing epics with stories and stories with tasks.
  • Treating Won't as unimportant rather than explicitly excluded.