CCBA Agile Business Analysis 2 — Questions and Answers
Question 1: In an agile project, what is the PRIMARY purpose of sprint retrospectives from a business analysis perspective?
- Reviewing completed code for quality
- Identifying improvements to the team's business analysis and collaboration practices (Correct answer)
- Estimating story points for the next sprint
- Reviewing acceptance test results
Correct answer: Identifying improvements to the team's business analysis and collaboration practices
From a BA perspective, retrospectives are opportunities to assess and improve business analysis practices — the quality of user stories, elicitation effectiveness, and collaboration with stakeholders.
Sprint retrospectives allow the team to reflect on what is working well and what needs improvement. From a business analysis perspective, this includes assessing: the quality and completeness of user stories entering the sprint, the effectiveness of elicitation and refinement sessions, collaboration between the BA and product owner, and how well the sprint's business outcomes aligned with stakeholder expectations.
Question 2: What is a 'definition of ready' (DoR) in agile business analysis?
- The criteria that define when the product is ready for production deployment
- The criteria that a user story must meet before it can be selected for a sprint (Correct answer)
- The definition of when a sprint is complete
- The acceptance criteria that a story must pass in UAT
Correct answer: The criteria that a user story must meet before it can be selected for a sprint
A Definition of Ready specifies the conditions a user story must meet before the team commits to it in sprint planning — ensuring stories are sufficiently understood and refined to be implementable.
The Definition of Ready (DoR) specifies the minimum criteria that a user story or backlog item must meet to be 'ready' for sprint planning. Common DoR criteria include: the story has clear acceptance criteria, it is estimated by the team, dependencies are identified, the team understands the business value, and it is appropriately sized (can be completed in one sprint). A DoR helps avoid bringing underprepared stories into sprints.
Question 3: How does the business analyst's role differ in agile versus traditional waterfall projects?
- Business analysts are not needed in agile projects
- In agile, the BA works more collaboratively with the team throughout, continuously refining the backlog rather than creating formal requirements documents upfront (Correct answer)
- In waterfall, the BA works during sprints; in agile, work is done in phases
- In agile, the BA role is replaced entirely by the product owner
Correct answer: In agile, the BA works more collaboratively with the team throughout, continuously refining the backlog rather than creating formal requirements documents upfront
In agile, the BA contributes throughout all sprints in a more collaborative, iterative way — continuously refining the backlog, facilitating elicitation, and supporting the product owner, rather than completing a requirements phase upfront.
In agile environments, business analysts work iteratively alongside the development team throughout the project. Rather than completing comprehensive requirements documentation before development begins, agile BAs continuously refine user stories, facilitate sprint planning and review sessions, conduct just-in-time elicitation, and support acceptance testing. The BA role often overlaps or is shared with the product owner in many agile teams.
Question 4: What is 'timeboxing' in agile and why is it relevant to business analysis?
- A technique for estimating how long requirements documentation will take
- A fixed time period (like a sprint) within which work must be completed, constraining the scope of business analysis activities (Correct answer)
- A method for scheduling stakeholder interviews
- A tool for tracking business analyst productivity
Correct answer: A fixed time period (like a sprint) within which work must be completed, constraining the scope of business analysis activities
Timeboxing fixes the duration of an iteration, which means business analysis activities must be scoped and prioritized to fit within the available time — it drives prioritization and just-in-time analysis.
Timeboxing sets fixed iteration lengths (typically 1-4 weeks), within which the team must complete all planned work. For business analysts, timeboxing means: user stories must be refined just-in-time (ready enough for the sprint without excessive upfront detail), analysis activities must be prioritized and scoped to fit the iteration, and there is a rhythm of continuous discovery rather than front-loaded analysis.
Question 5: In agile business analysis, what is the purpose of 'story mapping'?
- Mapping user stories to database tables in the technical architecture
- Creating a visual two-dimensional backlog organized by user activities and implementation priority (Correct answer)
- Drawing process flows for all user stories in the backlog
- Mapping stakeholders to the user stories they requested
Correct answer: Creating a visual two-dimensional backlog organized by user activities and implementation priority
Story mapping organizes user stories into a two-dimensional view: horizontal activities (the user's journey) and vertical depth (implementation priority), enabling teams to see the big picture and plan coherent releases.
Story mapping (developed by Jeff Patton) creates a narrative view of the backlog by arranging user stories into horizontal activities representing the user's journey through the solution, with higher-priority items near the top. This helps teams and stakeholders see the complete picture, identify gaps in the backlog, plan minimum viable product (MVP) slices that deliver a complete user experience, and prioritize incremental releases.
Question 6: What is 'continuous discovery' in agile business analysis?
- Running Selenium automated tests throughout the project
- An ongoing practice of learning about users, validating assumptions, and refining requirements throughout the product lifecycle (Correct answer)
- Discovering and logging system defects continuously
- Conducting daily elicitation interviews with stakeholders
Correct answer: An ongoing practice of learning about users, validating assumptions, and refining requirements throughout the product lifecycle
Continuous discovery is the practice of ongoing learning about users and validating assumptions throughout the product lifecycle, rather than treating discovery as a one-time upfront phase.
Continuous discovery is a product management and business analysis practice where teams engage in regular user research, assumption testing, and requirement refinement throughout the product lifecycle — not just at the beginning. This includes regular user interviews, usability testing, analytics review, and hypothesis-driven experimentation. It acknowledges that understanding of user needs is never complete and must evolve as the product and market evolve.
CCBA Agile Business Analysis 2
In an agile project, what is the PRIMARY purpose of sprint retrospectives from a business analysis perspective?