A User Story is a short, user-focused description of a feature in a standardised template:
> As a [role], I want [goal], so that [reason].
Example: "As a sales manager, I want to see my team's pipeline by stage in one dashboard, so that I can identify deals that need attention."
The format forces three things:
- Identifying the user — not "the system should..." but "as a sales rep". Reveals which role benefits.
- Articulating the goal — what the user wants to accomplish.
- Capturing the reason — why it matters. Distinguishes high-value from low-value features.
User stories often come with acceptance criteria — observable conditions that prove the story is done.
> Given I am a Sales Manager logged into Salesforce > When I open the My Team's Pipeline dashboard > Then I see a chart of opportunities grouped by Stage, filtered to my direct reports.
The Given/When/Then format makes acceptance criteria testable.
Why user stories beat traditional specs:
- User-centric — keeps the team focused on outcomes, not features.
- Fits Agile cadence — small enough to ship in one sprint.
- Conversation starter — story prompts questions that surface details.
- Estimatable — small stories are easier to estimate than monolithic specs.
Common mistake: writing technical tasks as "user stories" ("As a developer, I want to refactor the trigger handler so it's bulkified"). Those are technical tasks; reserve user stories for actual user-facing value.
Senior consultants help product owners write good user stories — small, valuable, independent, testable.