User stories are often described by their format. That's the wrong place to start.
The real definition:
"User Story is a representation of the customer need expressed as a small, concise statement of a feature needed to deliver value." — BABOK / IIBA Agile Extension
The format (As a… I want… so that…) is just a container. What matters is the value the story points to and the conversation it triggers. A story without a real "so that" clause — where the why is either missing or duplicates the what — is a symptom of a team that's building features without understanding the need behind them.
Job Stories approach the same need differently:
"When [situation], I want to [motivation], so I can [expected outcome]."
Job Stories come from Jobs-to-be-Done and focus on context and motivation rather than user persona. They're useful when the "who" is hard to pin down but the "when" and "why" are clear. I've used both on different projects — user stories for stakeholder-facing features, job stories when the real driver was a behavioral trigger rather than a role.
Decomposition is the skill of splitting large items into sprint-sized slices that still deliver real value. The hard constraint: every slice must be vertically thin — it has to work end-to-end, even if the experience is narrow. A slice that's technically complete but delivers nothing a user can touch is horizontal slicing — and it delays feedback.
The INVEST criteria apply here: each story should be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Exam tip: For PSPO, user stories are a technique, not a Scrum requirement. The Scrum Guide doesn't mention them. Any question implying stories are mandatory is a distractor.