IIBA-AAC key terms

The IIBA framework that applies business analysis practices to agile initiatives, organized around a mindset, a set of guiding principles, and three planning horizons. It describes how analysis work changes rather than replacing core business analysis knowledge.

The set of values and behaviors that shape how an analyst approaches agile work: embracing change, collaborating continuously, delivering value early, and treating analysis as a shared team responsibility rather than a single role's output.

The three time-based views in the Agile Extension: Strategic, Initiative, and Delivery. Each horizon has a different scope, audience, and level of detail, and analysis activities recur across all three rather than happening once.

The longest planning view, focused on understanding the enterprise, its market, and its direction. Work here includes analyzing the business context, defining a vision, and identifying where change will create the most value.

The middle planning view where strategic intent is turned into a funded, bounded effort. Analysis focuses on defining scope, prioritizing a backlog, and deciding how value will be delivered incrementally.

The shortest planning view, concerned with the day-to-day creation of working solutions. Analysis here centers on detailed requirements, acceptance criteria, and continuous feedback from the team and stakeholders.

A clear statement of what benefit a product or service offers, to whom, and why that audience would choose it over alternatives. It anchors prioritization by connecting features to a reason customers care.

A one-page visual template for describing how an organization creates, delivers, and captures value. Sections cover customers, channels, revenue, costs, and key activities, giving analysts a shared map for strategic discussion.

The smallest release that lets a team test a core hypothesis with real users while spending the least effort. It is built to generate learning, not to be a scaled-down final product.

An approach where work begins with an explicit, testable belief about user or business behavior, and each release is designed to confirm or reject it. Results inform the next iteration rather than being treated as failure.

An ordered list of pending work items such as features, stories, and defects. Ordering expresses priority and expected value, and the list is refined continuously rather than fixed at the start.

The ongoing activity of reviewing, clarifying, splitting, and reordering backlog items so the most valuable ones are ready for delivery. It is continuous rather than a one-time requirements phase.

A short description of a need written from a user's perspective, often in the form role, goal, and benefit. It is a placeholder for a conversation, not a complete specification.

The conditions a story must satisfy to be accepted by the customer or product owner. They clarify intent and provide a basis for testing, and are usually agreed before development begins.

A shared checklist describing what it means for any increment to be considered complete, such as tested, documented, and integrated. It applies to all work and raises quality expectations over time.

A team's agreed criteria for when a backlog item is clear, small, and testable enough to start work. It reduces mid-iteration surprises and supports predictable delivery.

A usable, potentially shippable addition to the product produced within an iteration. Each increment builds on prior ones and should be complete enough to deliver value on its own.

A short, fixed timebox in which a team analyzes, builds, and reviews a slice of work. Its regularity creates rhythm for feedback and planning, and scope is protected once it begins.

Any person or group affected by or able to influence an initiative, including users, sponsors, operations staff, and regulators. Effective analysis identifies them early and engages them at the right depth.

A visual model that plots stakeholders by influence, interest, or impact to guide engagement effort. It highlights gaps in representation and is revisited as the initiative evolves.

A representative description of a user type built from research, capturing goals, behaviors, and pain points. Personas help teams make design and prioritization decisions from the user's point of view.

Working jointly with stakeholders and team members to discover and refine needs, rather than gathering requirements through one-way handoffs. Frequent, direct conversation replaces elaborate documentation as the primary channel.

Designing and guiding group sessions, such as workshops or story mapping, so participants reach shared understanding and decisions. Good facilitation draws out quieter voices and keeps discussion focused on outcomes.

A technique that arranges user activities along a horizontal backbone and places detailed stories vertically beneath them by priority. It gives a whole-product view and helps slice releases around end-to-end value.

The continuing act of ranking work by value, risk, cost, and urgency so the team always addresses the most important items first. Techniques include weighting criteria, ranking, and simple relative comparison.

A prioritization scheme that sorts items into must-have, should-have, could-have, and will-not-have categories for a given timebox. It forces explicit agreement about what is essential versus negotiable.

A recurring team session to inspect how work is going and choose improvements for the next iteration. It focuses on process and collaboration, not on judging individuals.

The habit of regularly examining practices and outcomes and making small, deliberate adjustments. In agile analysis it applies to requirements approaches and team process alike, driven by observed evidence.

Choosing what to build or change based on observed data, such as usage metrics, experiments, and feedback, rather than opinion or hierarchy. It requires defining measures before work starts.

A leadership stance in which the person in authority removes obstacles, coaches the team, and protects its focus rather than directing tasks. It shifts decision authority toward those closest to the work.

A group that decides how to accomplish its work and who does what, within agreed boundaries. Analysts on such teams contribute skills rather than assigning tasks from outside.

The role accountable for maximizing product value by ordering the backlog and clarifying intent. This person is the primary point of contact for questions about what to build and why.

A flexible contribution rather than a fixed job title: the analyst may facilitate discovery, model needs, refine stories, or coach stakeholders. Responsibilities are shared and adjusted to what the team lacks.

Deciding how much specification an item needs based on its proximity to delivery and its uncertainty. Near-term work gets precise detail; distant work stays coarse until more is learned.

Needs that become visible only as users interact with working software and the team learns. Agile analysis expects them and plans for revisiting understanding rather than freezing scope early.

A structured cycle in which output is reviewed by users or stakeholders and the resulting insight changes subsequent work. Shorter loops reduce the cost of being wrong.

The sequence of activities that takes a need from idea to delivered value, including waits and handoffs. Mapping it exposes delays and waste that analysis can help remove.