IIBA-AAC Practice Questions

A well-written user story is intentionally brief and serves as a "promise for a conversation." Its primary purpose is to articulate a user need from their perspective, thereby initiating a collaborative dialogue among the delivery team, product owner, and stakeholders. This conversation is crucial for exploring the context, clarifying details, defining acceptance criteria, and reaching a shared understanding of the work to be done. The story card itself is not the requirement; the requirement is embodied in the combination of the card, the conversation, and the confirmation (the 3 Cs).

B. Is detailed and ready for build activities: A user story is not a detailed specification. The necessary details emerge from the conversation that the story card initiates, just prior to development.

C. Eliminates the need for further conversation: This is the opposite of a user story's intent. A user story is specifically designed to encourage and necessitate conversation, not eliminate it.

D. Captures all details about customer needs: A user story is a concise placeholder, not a comprehensive document. It captures the essence of a need, but the full details are uncovered through collaborative discussion.

1. IIBA. (2017). Agile Extension to the BABOK® Guide (Version 2).

Section 7.16.2

Description: "User stories are brief textual descriptions of functionality... They are deliberately not detailed to allow for conversations between the team and the stakeholders to clarify the details just before implementation."

Section 7.16.3

Elements (The 3Cs): "The conversation is the most important part of the user story. It is the collaborative dialogue between the delivery team

product owner

and stakeholders to flesh out the details of the user story..."

2. Lucassen

G.

Dalpiaz

F.

van der Werf

J. M. E.

& Brinkkemper

S. (2016). The use and effectiveness of user stories in practice. In 2016 IEEE 24th International Requirements Engineering Conference (RE) (pp. 205-214). IEEE.

Section II.A

User Stories: "User stories are meant to be conversation starters

rather than being contracts or detailed specifications." This peer-reviewed paper reinforces that the fundamental role of a user story is to facilitate communication. (DOI: 10.1109/RE.2016.29)

The activity described is task planning, which is a core part of iteration planning in agile methodologies. During this event, the delivery team selects a set of product backlog items for the upcoming increment. They then decompose these items (such as user stories) into smaller, more granular tasks required to complete the work. Team members then typically self-assign or are assigned these tasks. This process focuses on how the team will accomplish the selected work within the iteration.

A. Release planning: This is a higher-level planning activity that determines the features and timeline for a product release, which typically spans multiple iterations.

C. Resource planning: This is a broader, often traditional, project management term for allocating all types of resources (people, budget, equipment) over a longer term.

D. User story writing: This is the act of creating and refining product backlog items, which occurs before the planning workshop described in the question.

1. IIBA

Agile Extension to the BABOK® Guide

Version 2

2017. Section 4.5

"Plan the Iteration

" describes this process. Specifically

section 4.5.3.1

"Break Down the Work

" states: "The delivery team breaks down the items into the tasks required to complete the work. This provides a more accurate basis for estimation and progress tracking." (Page 48). This directly aligns with the question's description.

2. Sutherland

J.

& Schwaber

K. (2020). The Scrum Guide. The official guide to Scrum describes the Sprint Planning event. It states

"For each selected Product Backlog item

the Developers plan the work necessary to create an Increment that meets the Definition of Done... The Product Backlog items selected for the Sprint plus the plan for delivering them is called the Sprint Backlog." This planning of the necessary work is synonymous with task planning. (Page 9).

The scenario describes the technique of Story Elaboration. This is a just-in-time analysis activity where the team decomposes and refines user stories. It begins with a high-level user story (a broad view) and progressively adds details, clarifies scope, and defines acceptance criteria. The goal is to achieve a shared understanding and create a story that is ready for the delivery team to begin implementation (solution build activities). This process of drilling down into granularity is the core of story elaboration.

B. Real options: This is a decision-making technique used to manage uncertainty by deferring commitments, not a method for detailing requirements for implementation.

C. Detailed story: This describes the output or artifact resulting from the elaboration process, not the technique or activity itself that the team is performing.

D. Backlog management: This is a broader process that includes prioritizing, ordering, and maintaining the entire backlog. Story elaboration is a specific refinement activity within backlog management.

International Institute of Business Analysis. (2017). Agile Extension to the BABOK® Guide (Version 2).

Section 7.16 Story Elaboration

7.16.1 Purpose: "Story elaboration is used to discover the underlying details of a user story."

Section 7.16.2 Description: "Story elaboration is an ongoing

just-in-time analysis activity that occurs over the life of a user story... The goal is to get the story to a state where the delivery team has a shared understanding of the scope and acceptance criteria for the story."

Section 7.2 Backlog Management: This section describes the broader activities of organizing and prioritizing work

confirming that the question describes a more specific sub-activity.

Section 7.13 Real Options: This section defines Real Options as a decision-making technique for handling uncertainty

which is different from the requirement detailing process described.

Maintaining the integrity of an agile backlog means ensuring it remains a relevant, prioritized, and valuable source of work. A key practice in backlog management (or refinement) is to regularly review items to ensure they are still aligned with the current product vision and goals. Monitoring for "staleness" involves identifying items that have not been worked on or discussed for a long time and may no longer be relevant or valuable. This proactive cleanup prevents the backlog from becoming bloated with outdated requests, ensuring the team focuses on delivering current value.

A. Delaying changes is an anti-pattern in agile, as it allows the backlog to become disconnected from current business needs.

B. Developing a business case for all changes introduces excessive overhead and bureaucracy, hindering the team's ability to respond quickly.

D. Ensuring all changes are approved can create bottlenecks and disempower the team, contradicting agile principles of collaboration and autonomy.

---

IIBA. (2017). Agile Extension to the BABOK® Guide

Version 2.

Section 7.2

Backlog Refinement: This section describes the ongoing process of keeping the backlog orderly.

Section 7.2.3

Elements: This section explicitly lists activities for backlog refinement

including "removing user stories that no longer appear relevant" and "re-assessing the relative priority of stories." This directly supports the concept of monitoring for and acting upon stale items to maintain backlog integrity.

Sutherland

J.

& Schwaber

K. (2020). The Scrum Guide. Scrum.org.

Section on Product Backlog Refinement: The guide states

"Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items... This is an ongoing activity to add details

estimates

and order to items." Removing or updating stale items is an implicit and necessary part of this process to maintain a well-ordered backlog.

This scenario describes a fundamental agile principle of using feedback from delivered increments to inform future development. The team is engaging in a learning cycle. By analyzing feedback on what has already been built, they can validate or invalidate the assumptions that underpin the entire solution. This process allows them to determine if the planned remaining components are still relevant, valuable, and aligned with the evolving understanding of stakeholder needs. In essence, they are assessing if the remaining work is "still appropriate" to achieve the desired outcome.

A. Impacting other initiatives: While feedback might uncover dependencies, its primary purpose in this context is to assess the value and direction of the current initiative.

B. Supported by management: Feedback from users on a delivered component is not a direct measure of management's continued support for the project's completion.

C. Likely to be completed: Feedback on the value or functionality of a component does not determine the team's capacity or the technical feasibility of completing the remaining work.

1. IIBA

Agile Extension to the BABOK® Guide

Version 2

2017.

Section 4.2.3

Feedback and Learning: "Agile business analysis is based on a continuous feedback and learning loop... This learning is used to determine what to do next." This directly supports using feedback to decide if the remaining components are still the appropriate next steps.

Section 7.3.4

Backlog Refinement: This section describes the ongoing process where "the team discusses

estimates

and prioritizes the remaining items." This process is fueled by new information and feedback

ensuring the backlog (remaining components) remains appropriate and valuable.

Section 4.2.2

Deliver Value: "Feedback on the delivered solution is used to determine the next most valuable thing to deliver." This implies a continuous assessment of what is appropriate to build next based on feedback from what was just delivered.

Behavior Driven Development (BDD) is a collaborative approach that unites technical and non-technical stakeholders. It uses a shared, natural language format (like Gherkin's Given/When/Then syntax) to create a common understanding of desired system behaviors before development begins. This process inherently fosters an environment of constructive communication and collaboration. By defining acceptance criteria in this clear, unambiguous way, teams can continuously validate that the solution meets the strategic intent, thereby supporting continuous improvement.

A. Product Roadmap: A Product Roadmap is a high-level, strategic artifact that communicates the product vision and direction; it does not, by itself, create a collaborative working environment.

B. Reviews: Reviews (e.g., retrospectives, sprint reviews) are specific, time-boxed events for feedback and inspection. While they support collaboration, they are activities within a process, not the overarching approach to create the environment itself.

D. Release Plans: A Release Plan is a tactical document that outlines the timeline and scope for upcoming releases. Its primary focus is on scheduling and delivery, not on fostering a collaborative culture.

1. International Institute of Business Analysis (IIBA). (2017). Agile Extension to the BABOK® Guide (Version 2).

Section 7.4

Behavior Driven Development (BDD): This section describes BDD as a technique that "helps to ensure all stakeholders have a shared understanding of the desired behavior of the system before implementation begins... It is a collaborative approach that defines the acceptance criteria for a user story." (p. 82). This directly supports BDD as the correct answer for fostering collaboration and shared understanding.

Section 7.16

Product Roadmap: This section defines a roadmap as a tool to "describe how a product is likely to grow" and to "communicate the product direction." Its purpose is communication of a plan

not the creation of a collaborative environment. (p. 106).

Section 7.18

Reviews: This section explains that reviews are used to "evaluate a work product." While collaborative

they are distinct events

unlike the continuous collaborative nature of BDD. (p. 110).

Chapter 4

The Delivery Horizon: This chapter discusses release planning as a tactical activity focused on what will be delivered in the near term

distinguishing it from the strategic and cultural aspects addressed by BDD. (pp. 29-35).

When a user story is too large to be completed within a single iteration, the correct agile technique is story decomposition. This process involves breaking down a large story (often called a compound story or an epic) into smaller, more manageable stories. Each resulting smaller story should still be independent, negotiable, valuable, estimable, small, and testable (INVEST). This allows the team to deliver value incrementally, improve estimation accuracy, and reduce the risk associated with large, complex work items.

A. MoSCoW approach: This is a prioritization technique (Must have, Should have, Could have, Won't have) used to rank features, not to break down a single large story.

C. Epic analysis: While an epic (a very large story) is analyzed, "epic analysis" is not a formal technique. The action of breaking it down is called decomposition.

D. Story partitioning: This is a specific strategy or method of decomposition, but "story decomposition" is the name of the overarching, fundamental technique itself.

1. IIBA®

Agile Extension to the BABOK® Guide

Version 2

2017.

Section 7.1

Story Decomposition (Page 107): "Story decomposition is a technique to represent the requirements for a solution at different levels of abstraction... Stories that are too large to be completed in a single iteration are decomposed into smaller stories until they are the right size for the team to complete in an iteration." This directly supports the correct answer.

Section 7.1.3

Elements (Page 108): The guide lists common ways to decompose stories

such as by user role

workflow steps

or business rule complexity

which reinforces that decomposition is the primary technique.

Section 5.3

Prioritization (Page 81): This section describes various prioritization schemes

including MoSCoW

confirming its purpose is for ranking relative importance

not for sizing or splitting work items.

The team's decision to enforce a "sign-off" on requirements is a direct shift from a collaborative, partnership-based approach to a more rigid, contractual one. This action is taken to lock down scope and create a formal agreement that can be used to resist future changes, which is characteristic of contract negotiation. It fundamentally undermines the agile value of working closely and continuously with the customer to discover and refine their needs throughout the delivery lifecycle. Instead of collaborating to manage change, the team is creating a process to prevent it, which is the essence of an adversarial, contract-based relationship.

A. Individuals and interactions over process and tools: While a new process (sign-off) is being introduced, the core violation is its contractual and adversarial nature, making D a more specific and accurate answer.

B. Prioritizing outputs over outcomes: This describes an agile anti-pattern but is not one of the four core values stated in the Agile Manifesto, which the question is referencing.

C. Working solutions over comprehensive documentation: The problem is not the documentation itself, but its use as a rigid contract to halt collaboration and change, which is the central point of option D.

1. Manifesto for Agile Software Development. (2001). The third value explicitly states

"Customer collaboration over contract negotiation." The scenario described is a classic example of reverting to contract-style negotiation instead of maintaining collaboration. Retrieved from agilemanifesto.org.

2. IIBA. (2017). Agile Extension to the BABOK® Guide

Version 2. In Section 3.2.2

"The Agile Mindset

" the guide explains that "Customer Collaboration over Contract Negotiation" fosters a cooperative relationship rather than an adversarial one. Introducing a sign-off to manage an "indecisive" customer creates an adversarial dynamic.

3. Cohn

M. (2010). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional. In Chapter 3

"Agile Values

" Cohn discusses that agile teams prefer to collaborate with customers on an ongoing basis rather than negotiating a detailed contract (like a signed-off requirements document) upfront. The sign-off represents a move toward the "contract negotiation" side of the value statement.

Dependencies in a backlog force work to be done in a specific sequence, often creating large, interconnected batches. This prevents the delivery of small, independent increments of value. The core agile principle of learning and adapting through rapid feedback is compromised because feedback can only be gathered after the entire chain of dependent items is complete. This delay in learning hinders rapid decision-making, slows down overall delivery cadence, and risks misalignment with evolving strategic goals, as adjustments cannot be made based on timely stakeholder input.

B. Daily standups: Daily standups are a mechanism to identify and manage impediments like dependencies, not the principle being compromised by their existence.

C. Retrospectives: Retrospectives are events for process improvement where the negative impact of dependencies might be discussed, not the concept being limited by them.

D. Thinking like a customer: While crucial, dependencies are often technical or organizational constraints that can exist even when a team is focused on customer value.

1. International Institute of Business Analysis. (2017). Agile Extension to the BABOK® Guide

Version 2.

Section 4.3.3

Learn through Feedback and Retrospection: "Agile business analysis practitioners seek to enable a continuous flow of value to the customer... This is accomplished through frequent feedback loops which enable the team to deliver something of value

get feedback on that value

and then adapt their future work based on that feedback." Dependencies directly inhibit this "frequent" aspect.

Section 3.2.5

Understand What is Doable: "Dependencies between backlog items limit the ability to choose the order in which to deliver them." This limitation is what breaks the ability to create fast feedback loops by delivering small

independent items.

Section 7.4.3

Backlog Refinement

.2 Elements: "Dependencies: Business analysis practitioners identify and analyze dependencies between backlog items. Dependencies may constrain the options for sequencing work." This constraint directly impacts the ability to deliver incrementally and get feedback.

A well-formed user story traditionally follows the "As a , I want , so that " template. The third component, the "so that" clause, is crucial as it explicitly defines the benefit or business value the user gains upon the story's implementation. This element provides the context and rationale ("the why") for the development team, which is essential for making correct implementation decisions and for prioritizing the story against others. Quality checking ensures this value proposition is clear, as delivering value is a core principle of agile development.

A. The explanation of the story’s cost: Cost is an estimation attribute used for planning and prioritization, not a fundamental component of the user story's narrative structure itself.

B. The stakeholder responsible for testing: This information is typically part of the team's workflow, acceptance criteria, or Definition of Done, not a core attribute of the user story's description.

D. The title describing the goal of the delivery cycle: The goal of a delivery cycle (e.g., a Sprint Goal) is a higher-level objective that a collection of user stories helps achieve, not an attribute of an individual story.

International Institute of Business Analysis (IIBA). (2017). Agile Extension to the BABOK® Guide (Version 2).

Section 7.16.2

Elements: This section details the three primary elements of a user story: Role

Goal

and Benefit (or Motivation). It explicitly states

"The benefit describes the business value the user role receives when the story is implemented." This directly supports the correct answer.

Section 7.16.3

Usage Considerations: This section discusses the INVEST criteria for quality user stories

where "V" stands for "Valuable." It states

"A user story must be valuable to the customer... The 'so that' clause of the user story format is intended to articulate the value." This reinforces that the benefit is a key quality attribute.