A user story describes what a user needs and why. It should be small enough to build, clear enough to test, and connected to a real business outcome.
User story format
As a [user], I want [capability], so that [business outcome].
Examples
- As an operations analyst, I want to filter settlement breaks by counterparty so that I can focus on the breaks assigned to my team.
- As a manager, I want to export open reconciliation breaks so that I can review them in Excel before the daily operations meeting.
- As a support analyst, I want to view complete trade details so that I can investigate user queries without switching systems.
- As a compliance user, I want invalid reporting records to be flagged before submission so that we can correct errors before sending data to the regulator.
- As an administrator, I want to assign users to roles so that each user only sees the actions they are allowed to perform.
Common mistakes
- Writing system tasks instead of user needs
- Missing the business reason
- Making the story too large
- Adding too many unrelated requirements
- Writing acceptance criteria that cannot be tested