What is a user story?
A user story is a short description of a feature or requirement written from the end user's perspective, typically following the format: "As a [type of user], I want [goal], so that [reason]." User stories capture what a user needs and why, without prescribing how the solution should be built. They are the primary unit of work in many agile teams, serving as the bridge between business requirements and development tasks.
The format is deliberately simple. "As a team lead, I want to filter the board by assignee, so that I can see what each person is working on" communicates the who, the what, and the why in a single sentence. The developer reads the story and understands the user's need without being told which API endpoint to build or which UI component to use. This separation of intent from implementation gives the development team freedom to choose the best technical approach.
Why user stories matter
User stories keep development anchored to user value. Technical requirements like "add a filter dropdown to the board header" describe implementation. User stories like "as a team lead, I want to filter by assignee" describe value. The difference matters because implementation can be achieved in many ways, some better than others. When the team understands the underlying need, they can propose solutions the product owner may not have considered.
Stories also serve as conversation starters, not comprehensive specifications. The story itself is intentionally brief. The detailed requirements emerge through discussion between the product owner and the development team during sprint planning or backlog grooming. This prevents the common failure mode of writing exhaustive requirement documents that no one reads.
Writing good user stories
Good user stories follow the INVEST criteria: Independent (can be developed without depending on other stories), Negotiable (details are discussed, not dictated), Valuable (delivers something the user cares about), Estimable (the team can gauge its size), Small (completable within a single sprint), and Testable (there is a clear way to verify it works).
Acceptance criteria complement the story by defining the specific conditions that must be true for the story to be considered done. For the filter example: "Board shows only cards assigned to the selected user. Selecting 'All' removes the filter. Filter persists until changed." These criteria become the checklist the team tests against before moving the card to Done.
How Flux handles user stories
In Flux, user stories map naturally to cards on a kanban board. The card title holds the story summary, the description field holds the full story and context, and checklists capture acceptance criteria as checkable items. Labels can tag stories by epic, feature area, or priority. The AI assistant can generate structured cards from a plain-language description, automatically filling in the title, description, and checklist items - which reduces the overhead of writing stories during planning sessions.
Related terms
See also: Epic, Backlog, Sprint Planning.