EXIN BCS Agile BA Professional common mistakes
EXIN BCS Agile BA Professional · Understand the traps and how to avoid them.
Answering questions about the agile BA role by describing a traditional waterfall analyst who produces a complete requirements specification up front and hands it to the team, rather than describing someone who collaborates continuously with the team and product owner to shape and refine understanding just in time.
Most candidates come from a waterfall or hybrid background where the BA's value is measured by document completeness. They carry that mental model into scenario questions and pick the option that sounds most rigorous and thorough, even when the scenario explicitly describes an iterative delivery with a product owner and short sprints.
What to do instead
Before the exam, write a one-paragraph definition of the agile BA role in your own words: eliciting and framing problems, facilitating shared understanding, helping the product owner order the backlog, and elaborating detail at the last responsible moment. For every scenario question, ask 'does this option keep the BA in continuous conversation with the team, or does it push them back into a document-handover posture?' Eliminate the latter even when it sounds more professional.
Treating 'agile' as a single fixed method and choosing answers that assume Scrum mechanics (sprint planning, daily scrum, a single product owner) in scenarios that describe Kanban, flow-based or scaled environments, or that describe the BA working across several teams.
Scrum is the most familiar agile framework, so candidates pattern-match every question to it. Exam scenarios deliberately vary the context, and options that impose Scrum artefacts on a flow-based team are wrong even though they sound agile.
What to do instead
Build a comparison table of Scrum, Kanban and scaled setups covering: how work is pulled, who owns prioritisation, how requirements are elaborated, and the cadence of feedback. In each scenario, first identify the delivery approach from the wording (e.g. 'continuous flow', 'work in progress limits', 'multiple teams on one product'), then choose the option that fits that approach rather than defaulting to sprints.
Selecting the option that maximises documentation, sign-off and traceability in a scenario about uncertainty, on the grounds that it reduces risk, instead of choosing the option that embraces emerging requirements and short feedback loops.
Candidates equate risk reduction with control and control with documentation. The agile principle of welcoming changing requirements and the value placed on working software over comprehensive documentation are tested directly, and the 'safer' answer is usually the intended distractor.
What to do instead
Learn the four value statements and the twelve principles well enough to state which one a given option violates. Practise a rule: if an option's main effect is to freeze scope or obtain approval before learning, it contradicts agile values unless the scenario involves a genuine regulatory or contractual constraint that the question explicitly names.
Assuming the product owner alone owns all prioritisation and that the BA should simply accept the ordering, missing options where the BA adds value by surfacing trade-offs, dependencies, technical risk and stakeholder impact to inform that ordering.
Candidates over-correct from waterfall, where the BA controlled scope, into a caricature of agile where the BA has no influence over what gets built. Exam questions often test the BA's contribution to value-based prioritisation, not just elicitation.
What to do instead
Memorise the distinction between owning the backlog (product owner) and informing the backlog (BA, team, stakeholders). Practise answering: what information does the BA bring to a prioritisation conversation, and how do they present it without usurping the product owner's decision rights? Choose options that influence decisions through evidence rather than options that seize or abdicate the decision.
Ignoring the team in stakeholder questions and answering as if stakeholders are only external business users, so options about the BA facilitating shared understanding between developers, testers and business representatives get overlooked.
Traditional stakeholder analysis focuses on sponsors, users and regulators. In agile delivery the delivery team is a primary stakeholder group, and the BA's facilitation role inside the team is heavily examined.
What to do instead
When doing stakeholder analysis in practice or in questions, always include three rings: the delivery team, the product owner and business/domain experts, and external or regulatory parties. For each, ask what the BA needs to learn from them and what they need from the BA. Choose answers that build shared understanding across the rings rather than answers that route all communication through documents or through the product owner alone.
Choosing 'escalate to the sponsor' or 'arrange a meeting with all stakeholders' as the response to conflict or disagreement, rather than choosing a facilitated, incremental approach such as a focused workshop, a prototype or a time-boxed spike to resolve the specific uncertainty.
Candidates want a decisive, senior-sounding action. Agile answers favour small, fast, collaborative experiments over escalation and large gatherings, and the exam rewards proportionality.
What to do instead
Learn the standard facilitation and collaboration techniques and when each fits: workshops for alignment, modelling for shared understanding, prototyping for unclear requirements, observation for tacit process knowledge, and retrospectives for team improvement. Match the technique to the size and nature of the problem, and prefer the smallest intervention that produces learning.
Writing or selecting user stories that describe a solution ('the system shall provide a dropdown of regions') rather than a need in role-goal-benefit form, and then failing questions that ask which story is best formed or how to split a story.
Candidates default to functional requirement phrasing from traditional specifications. The role-goal-benefit structure and the INVEST qualities are examined directly, and solution-laden stories are the most common distractor.
What to do instead
Practise rewriting ten real requirements into 'As a , I want , so that ' form and check each against INVEST. For splitting, learn the standard patterns (by workflow step, by business rule, by data variation, by acceptance criteria) and be able to say which pattern suits a given large story.
Treating acceptance criteria and definition of done as interchangeable, or omitting non-functional criteria, when answering questions about when a backlog item is ready or complete.
Both describe conditions, so candidates conflate them. Acceptance criteria are specific to one backlog item and confirm the intended behaviour; definition of done is a shared team standard applied to every item. Non-functional qualities such as performance, security and usability are frequently the missing piece in 'what is wrong with this item' questions.
What to do instead
Write the distinction as two sentences and keep them in mind: acceptance criteria answer 'how will we know this item does what we intended', definition of done answers 'what does done mean for everything we build'. When reviewing a sample item, check for both, plus explicit non-functional criteria, and be suspicious of any option that treats done as a purely technical or purely business judgement.
Answering backlog refinement questions by describing one big upfront elaboration session that details everything before development starts, instead of continuous, proportionate refinement at the last responsible moment, with just enough detail for the near-term items.
Candidates translate 'refinement' into 'requirements phase'. The agile intent is progressive elaboration: the top of the backlog is detailed, the rest stays coarse until it is needed.
What to do instead
Learn the concept of the last responsible moment and the idea of a rolling wave of detail across the backlog. In questions, prefer options that concentrate detail on items about to be worked and keep distant items as placeholders, and reject options that require full specification of everything before any delivery begins.
Naming a technique without being able to say what it produces or when it is inappropriate, so questions that describe a situation and ask which technique fits are answered by familiarity rather than by matching the technique's purpose to the situation.
Candidates memorise technique names and definitions but not selection criteria. The exam tests judgement about fit, and several techniques (e.g. prototyping, observation, process modelling, decision tables, story mapping) overlap superficially.
What to do instead
Build a one-line card per technique covering: the question it answers, the artefact it produces, its cost, and the situation where it is the wrong choice. For example, story mapping answers 'what does the user journey look like and how do we slice it into releases', whereas a decision table answers 'what should happen under this combination of conditions'. Rehearse choosing between two plausible techniques in a described situation, and justify the choice in one sentence.