Free IIBA-AAC practice test: 30 questions with answers

The story gives no measurable check, so it cannot be verified as done. The story is not clearly dependent, too big, or fixed in its details, so Independent, Small, and Negotiable are not the criteria that are missing.

The definition of done is a shared checklist of quality criteria that applies to all work before it is considered complete. A task list, a story's acceptance criteria, and the agreement that a story is ready to start are different concepts.

Given-When-Then scenarios describe a context, an action, and an expected result in a structured way that testers and developers can share and automate. A narrative, design decisions, or a sign-off form do not give that executable, shared structure.

Work piling up before a column that is starving for items points to an upstream bottleneck, so the team should limit intake and clear that stage. Hiring developers, raising the development limit, or removing the column each treat a symptom or start more work without fixing the flow.

A cumulative flow diagram stacks item counts per workflow state over time, so a widening band reveals a bottleneck. A burndown shows sprint remaining work, velocity compares completed work, and a Gantt chart shows schedule, so none of them shows state counts over time.

A flat burndown followed by a late drop usually means work is finished in a batch at the end instead of incrementally, so the team has little visible progress mid-sprint. A fast team would show an early decline, and a flat chart does not always mean a block.

The Three Amigos practice is a short specification conversation among analyst, developer, and tester about a story's examples and edge cases. The stand-up, retrospective, and sprint review each serve a different purpose in the agile cadence.

Splitting stories into small testable slices and writing concrete examples before coding both support small, verifiable increments. Bundling work at the end and deferring all testing create large batches that cannot be verified early.

The Agile Manifesto values working software over comprehensive documentation and responding to change over following a plan. Delivering thin slices early gives the team feedback so priorities can change safely. The other options favor a fixed plan, a signed scope, or process over adaptation.

Eliminating waste means not building or keeping work that adds no value for the customer, such as speculative requirements. Amplifying learning, deciding late, and empowering the team are other Lean principles, not the one that removes unused work.

Agile teams use inspect-and-adapt: they try a small, bounded change and check whether it helps. A coordinator or a sign-off gate adds process rather than fixing the collaboration gap, and waiting for a manager goes against self-organizing teams.

Servant leadership in agile means removing obstacles and coaching, while the team owns its goals and how it does the work. Assigning tasks from above and requiring approval before action work against self-organization, so those two statements are wrong.

Sustainable pace means the team can keep working at a steady rate indefinitely, which protects quality and morale. Pushing overtime, postponing defects, or adding iterations to absorb backlog growth all trade long-term capacity for short-term output.

Psychological safety comes from norms where asking questions and challenging requirements is expected, and leaders show that behavior. Praising only some people, limiting questions, or keeping a junior member quiet does not create that openness.

Customer collaboration over contract negotiation means working closely with customers to shape priorities as they change. The other options reverse manifesto priorities by putting plans, tools, or documents ahead of adaptation and people.

A growth mindset in an agile team means treating early sprints as learning and asking for feedback on your own practice. Reusing waterfall deliverables, limiting yourself to recording decisions, or waiting for training all keep the analyst from collaborating.

An epic is the backlog item used for a large body of related work that is later broken into user stories. A spike is a research item, a defect is a fault to correct, and a sprint goal is a short objective for one iteration.

WSJF divides cost of delay by job size, so X scores 6 (30 divided by 5) and Y scores 10 (20 divided by 2). Y should go first because it delivers more value per unit of effort. The other options ignore that division or rely on risk or story counts, which WSJF does not use.

User story mapping arranges work along the user's journey and uses horizontal slices to find a releasable scope. Affinity diagramming, critical path analysis, and decision trees are useful techniques but do not produce a user-sequenced map with release slices.

Minimum marketable features (MMF) are the smallest set of features that makes a release worth selling to customers. A feature freeze, full regression scope, and gold-plating describe different release concepts and do not define the smallest worthwhile release.

With wide uncertainty, a target window that is revisited as learning occurs reflects what the team actually knows. Cutting testing, deleting the item, or publishing a fixed date as a guarantee each ignore the uncertainty in a harmful way.

Impact mapping is the technique that connects a goal to actors, impacts, and deliverables. Value stream mapping shows process flow, root cause analysis looks backward at problems, and SWOT analysis surveys an organization's position, so none of them makes that goal-to-deliverable link.

A time-boxed discovery spike reduces uncertainty before the team commits to scope, which suits an initiative with a strong case but unclear scope. Committing blindly, rejecting the work outright, or locking a fixed contract early all ignore that uncertainty.

A minimum viable product is the smallest version that tests a key assumption and produces validated learning with real users. The roadmap, architecture blueprint, and multi-year budget all describe commitments to full scope and do not test the hypothesis early.

A product vision describes the enduring outcome a product should achieve and guides which initiatives are worth pursuing. Feature lists, acceptance criteria, and cost records are useful artifacts but they are not the purpose of a vision.

Aligning initiatives with strategy means connecting them to measurable outcomes and reviewing them against the strategic goals before funding. Funding by headcount or approving whatever the largest customer asks for are not strategy-driven choices.

Outcome-based planning ties each initiative to a measurable business result, so investments are judged by what they change. Output, budget, and activity-based planning measure what is produced or spent, not whether the strategy is being achieved.

A product roadmap communicates direction and expected outcomes over time, and it is revised as the team learns. A fixed contract, a test plan, or a record of completed stories each fixes or reports details rather than guiding direction.

Choosing a first segment should weigh a validated problem that the product solves against the team's ability to reach those customers. Choosing by size alone, by the loudest sponsor, or by fewest competitors ignores whether the product fits a real need.

A vision describes the long-term future an organization aspires to create. A mission describes current purpose, a tactic is a near-term action, and a key performance indicator tracks progress, so only the vision fits the description.