How do you write a good user story? Can you give us an example from your experience?
RoleBusiness Analyst
DifficultyDifficult
TopicTechnical
Asked at
Why This Is Asked
No company-specific verbatim questions are publicly documented for IBM Philippines BA interviews; this is grounded in confirmed general topics like user story creation. IBM values BAs who can translate business needs into technical artifacts that drive efficient global delivery and agile development.
General Approach
Explain the standard template (As a, I want, So that), then provide a rich, real or hypothetical example. Highlight how you ensure stories are granular, unambiguous, and meet acceptance criteria. Mention INVEST or similar principles to show methodical thinking.
General Answer
A user story generally follows the template: "As a [type of user], I want [a goal or capability], so that [the benefit or reason]." For example: "As a returning customer, I want to save my delivery address, so that I don't have to re-enter it on every order." A good user story should meet the INVEST criteria: Independent (can be developed without depending on other stories), Negotiable (details can be discussed with stakeholders rather than fixed upfront), Valuable (delivers something meaningful to the user or the business), Estimable (the team can size the effort), Small (fits within a single sprint), and Testable (has clear acceptance criteria). Acceptance criteria are usually written separately, often in a Given/When/Then format, so it is unambiguous when the story is considered done. Writing stories this way, granular and unambiguous, keeps the backlog easy to prioritize and prevents scope creep during development.
PH Interview Gotcha
Some Filipino candidates over-generalize and say, 'Basta gagawa ako ng user story na may user, action, benefit' (I'll just make a user story with user, action, benefit) without concrete metrics or acceptance criteria. Avoid this by showing you know how to make stories specific and verifiable. Instead, present a story with precise performance targets and testable conditions.
Sample STAR Answer▾
S
Situation
While working on a healthcare claims processing system, the product owner handed me a vague requirement: 'Make the claim status update faster.' There was no clarity on which user role, what 'faster' meant, or what specific problem needed solving.
T
Task
I needed to break down the high-level request into clear, actionable, and testable user stories that the development team could estimate and implement.
A
Action
I conducted a follow-up session with the product owner and two end-users (claims processors) to uncover the exact pain point: they were waiting too long after clicking 'Submit' to see a confirmation. I then crafted the user story: 'As a claims processor, I want to receive a visual confirmation within 2 seconds of clicking Submit, so that I can proceed to the next claim without uncertainty.' I added acceptance criteria: the system must display a success toast notification within 2 seconds under normal load, and if processing takes longer, a spinner must appear. I aligned the story to the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
R
Result
The story was estimated at 3 story points and completed in one sprint. Post-deployment, the average processing cycle time per claim dropped by 18 seconds, and user satisfaction with the interface improved notably in the next survey.
Key Takeaway
A user story is not just a template; it captures real user need and measurable outcome.
Attempt Your Answer
Write your own answer, then get instant AI feedback graded against:
- •STAR Structure
- •Specificity & Numbers
- •Ownership Language
- •PH Workplace Context
Get AI feedback on your answer — free.
3 free AI-graded answers + 1 free mock interview, no card needed.
Sign Up FreeAlready have an account? Log in
Share Your Answer (0)
Sort
Sign in to join the conversation.
No answers shared yet — be the first to show how you'd approach this.