"Add an export button" describes a feature. A user story describes a user need. That distinction changes everything: it forces the team to ask why, not just what.
A user story describes a feature from the perspective of the person using it, following the format popularized by the Connextra template: "As a [role], I want [action], so that [benefit]". This format forces the team to articulate value for the user before even discussing the technical solution.
In the agile hierarchy, a user story sits between an epic (the big theme) and a technical task (the concrete work of a sprint): an epic breaks down into several user stories, each small enough to ship within a single sprint. The Scrum Guide doesn't formally define the user story (it's an XP practice, not Scrum itself), but it has become the de facto standard for feeding the backlog.
Can be developed and shipped without tightly depending on another story in progress.
Describes a need, not a fixed spec: the technical solution stays open for discussion with the team.
Delivers an identifiable benefit for the user or the business — otherwise, why do it?
Clear enough that the team can estimate the effort, even roughly.
Deliverable within a single sprint; otherwise it should be split into several stories.
Comes with checkable acceptance criteria — see also the Definition of Done.
"As a project manager, I want to export my schedule to PDF, so that I can share it with a client who has no access to the tool."
Acceptance criteria: the PDF includes every task visible on screen; the export works on mobile and desktop; the generated file is under 5 MB.
Notice what this phrasing avoids: it doesn't say "add a PDF export button" (the solution), it expresses the need — leaving the team free to propose the best implementation. The INVEST criteria itself was formalized by Bill Wake, referenced by the Agile Alliance.
Write your user stories, link them to your epics, and track them in your backlog. Free.