EXIN BCS Agile BA Professional key terms

The practice of applying business analysis activities such as elicitation, modelling and evaluation continuously and collaboratively within an agile delivery cycle, rather than producing a single complete specification before development starts.

Four stated preferences, such as valuing working software over comprehensive documentation, that guide how agile teams prioritise behaviour and outputs. They set the mindset from which agile business analysis practices are derived.

A recurring cycle in which a team reviews its product and working process at fixed intervals and changes what it does next. It underpins continuous improvement of both solutions and team practices.

A fixed, short timebox in which a team analyses, builds and tests a slice of the solution. Each iteration aims to produce something demonstrable so that feedback can inform the next cycle.

The accumulated, potentially shippable output produced by the end of an iteration. It represents added value that meets agreed quality criteria and can be demonstrated to stakeholders for feedback.

Fixing a maximum duration for an activity so that effort is bounded and decisions are forced before the deadline. Business analysts use it to keep workshops, elicitation and modelling sessions focused and productive.

Planning in detail only for the near term while keeping later work at a high level, refining it as knowledge grows. It replaces a single upfront plan with progressively elaborated intentions.

Eliciting and detailing requirements close to the point at which they will be built, so that they reflect the latest understanding. This reduces wasted analysis on features that may change or be dropped.

A style in which the person in a leadership role focuses on removing obstacles and enabling others to succeed rather than directing their work. It shapes how agile business analysts support teams and stakeholders.

A arrangement in which a business analyst represents or supports the product owner by refining backlog items, clarifying needs and answering team questions, while accountability for value and priority stays with the product owner.

The role accountable for maximising the value of the product and for ordering the backlog. This person decides priorities, accepts or rejects completed work and is the main channel for stakeholder input.

A visual model showing who is affected by or can influence a change, often grouped by interest and influence. It helps the team plan engagement and decide who to consult on which decisions.

The process of identifying stakeholders, understanding their needs, attitudes, influence and availability, and deciding how to engage each of them throughout delivery. It is revisited as the solution and context evolve.

A way of arranging stakeholders in concentric rings according to how directly they use or are affected by the solution, from the delivery team outward to wider society. It helps set appropriate engagement depth.

A fictional but evidence-based description of a typical user, including goals, context and behaviours. Personas keep discussions of requirements focused on real user needs rather than abstract roles.

A workshop technique that captures what a user says, thinks, does and feels in order to build shared understanding of their experience. It supports user-centred analysis and the discovery of unmet needs.

Designing and guiding a group session so that participants reach a shared outcome, using agreed ground rules, clear questions and visible capture of ideas. It is a core skill for collaborative agile analysis.

A group technique in which participants first write ideas individually and in silence before sharing them. It reduces anchoring on the loudest voice and produces more input in less time.

A short collaborative session involving business, development and testing perspectives to explore a backlog item and agree examples of expected behaviour before it is built. It surfaces gaps early and builds shared understanding.

An ordered, evolving list of everything that might be built to create the product, from features and stories to technical and knowledge work. It is the single source of intended change and is continuously refined.

The ongoing activity of reviewing, clarifying, splitting and reordering backlog items so that the most valuable ones are ready to be worked on. It is usually a short, regular conversation rather than a formal document.

A short statement of a need written from a user's perspective, typically naming the role, the goal and the benefit. It is a placeholder for a conversation rather than a complete specification.

A checklist for judging a well-formed user story: independent, negotiable, valuable, estimable, small and testable. It guides refinement and splitting decisions rather than acting as a rigid gate.

The conditions a backlog item must satisfy to be accepted by the product owner or customer. They make expectations testable and can be written as rules or as concrete examples.

A shared, explicit checklist describing the quality state an increment must reach before it counts as complete. It applies to all items rather than to one specific requirement.

An agreed set of conditions a backlog item should meet before the team takes it into an iteration, such as being understood, estimated and testable. It supports smooth flow without replacing judgement.

Breaking a large backlog item into smaller ones that each deliver value and can be completed within a short iteration. Common patterns include splitting by workflow step, business rule, data variation or user role.

A large, loosely defined body of work that is too big to complete in one iteration and is progressively broken down into smaller stories. It helps communicate intent at a level above detailed requirements.

The progressive detailing of a requirement through conversation, modelling and examples until the team understands it well enough to build and test it. Detail is added only as far as the near-term need requires.

A lightweight, evolving view of intended outcomes and the order in which they may be pursued over time. It communicates direction and trade-offs without committing to fixed dates and features.

The smallest version of a product that allows a team to test its key assumptions with real users and learn what to do next. It is a learning device, not simply a reduced feature set.

An approach in which expected behaviour is agreed through concrete examples expressed in structured language, which then guide development and automated tests. It links requirement conversations directly to verification.

A short collaborative workshop using coloured cards to break a story into rules, examples, open questions and the story itself. It exposes ambiguity and missing rules quickly before development begins.

A visual technique that starts from a goal and works outward through actors, impacts and deliverables, showing why each feature is being built. It connects backlog items to measurable business outcomes.

A ranking scheme that classifies items as must have, should have, could have or will not have for a given timebox. It makes trade-offs explicit and protects delivery of essential outcomes when time is fixed.

A regular team meeting in which members review how they worked, identify improvements and agree actions for the next iteration. It is the main vehicle for adapting team process.

The accumulated cost of shortcuts in design or code that make future change harder. Business analysts help make it visible so that it can be balanced against feature work in the backlog.

Framing a proposed change as a testable belief about an expected outcome, with measures that will confirm or refute it. It keeps analysis focused on value and learning rather than on delivering features.

A person who helps teams and stakeholders adopt and improve agile ways of working through teaching, mentoring and observation. They support, rather than replace, the team's own problem solving.