CAPM Business Analysis Frameworks Practice Question
A business analyst is working on a project to develop a mobile banking application. During the requirements analysis phase, the BA creates a set of user stories and acceptance criteria. The BA then conducts a peer review with the development team. The team points out that the stories are too large and vague to estimate. The BA needs to refine the requirements to make them actionable. The project is using an agile methodology with two-week sprints. What should the BA do?
⚠ Common exam trap
PMI often tests the misconception that adding more detail or creating a prototype is sufficient to make stories actionable, but the core agile requirement is that stories must be small enough to be estimable and completed within a single sprint.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Split the large user stories into smaller, more specific stories with acceptance criteria.
In agile methodologies, user stories must be small enough to fit within a single sprint and provide clear, testable acceptance criteria for estimation and development. Splitting large, vague stories into smaller, specific stories with acceptance criteria directly addresses the team's inability to estimate, enabling accurate sprint planning and incremental delivery. This aligns with the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable) for effective user stories.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Split the large user stories into smaller, more specific stories with acceptance criteria.
Why this is correct
Splitting oversized stories into smaller, specific ones with clear acceptance criteria makes each estimable and completable within a two-week sprint, directly resolving the team's complaint that the current stories are too large and vague to size.
- ✗
Add more detail to the existing user stories and acceptance criteria.
Why it's wrong here
Adding detail to oversized stories leaves them too large for a two-week sprint, so estimation stays unreliable. It tempts because vagueness is part of the complaint, and elaboration feels responsive. The real fix is splitting each story into smaller, independently deliverable slices, then enriching acceptance criteria per slice.
- ✗
Create a prototype to clarify requirements and then rewrite stories.
Why it's wrong here
Prototyping adds build effort and delays refinement without splitting the oversized stories, so they remain unestimable. It tempts because prototypes clarify ambiguous requirements, which suits uncertain scope. Here the team's blocker is story size and vagueness, addressed by decomposition and acceptance-criteria detail, not visual mock-ups.
- ✗
Ask the development team to re-estimate the stories as they are.
Why it's wrong here
Re-estimating unchanged stories cannot succeed because the team already stated they are too large and vague to estimate. It tempts as a quick way to unblock sprint planning, but estimation requires decomposed, testable stories. The BA must refine the backlog first, splitting epics into sprint-sized items with clear acceptance criteria.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CAPM question from scratch — 451 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CAPM practice question is part of Courseiva's free PMI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CAPM exam.