The User Story is a format for expressing a software requirement using the template “As a [role], I want [feature], so that [benefit]” — a structure that transforms a simple request into a three-part sentence in which the first part is always “user,” the second part is what someone actually wants, and the third part is a justification fabricated to satisfy the template.
The User Story was invented by Kent Beck as part of Extreme Programming, where it served its original purpose: a placeholder for a conversation. The story was written on an index card — physically small, deliberately incomplete — as a reminder to talk to the customer. The card was not the requirement. The conversation was the requirement. The card was the sticky note that said “have conversation.”
The industry kept the card. The industry lost the conversation.
The Template
The canonical template is:
As a [role], I want [feature], so that [benefit].
In practice:
As a user, I want to log in, so that I can access my account.
The “As a” clause is almost always “user.” Occasionally “admin.” Rarely anything specific enough to inform the implementation. The template invites role-playing but delivers casting — everyone is “user,” the way every character in a school play is “Villager #3.”
The “I want” clause is the only useful part. “I want to log in.” “I want to search.” “I want to download my invoice.” This is the requirement. This is what the developer will build. Everything before and after it is ceremony.
The “so that” clause is the justification — the why. In theory, this forces the writer to articulate the business value. In practice, the “so that” clause is either obvious (“so that I can access my account” — yes, that is why people log in), redundant (“so that I can use the login feature”), or invented specifically to fill the third blank (“so that this story complies with the story format”).
The Lifelog Alternative
In the lifelog, requirements arrive as four words:
“You need related posts.”
— Gaby, The Feature That Wasn’t
No template. No role. No justification. Four words, followed by a conversation, followed by a feature that shipped in forty-seven minutes without a single line of new code. The “As a” was implied (reader). The “I want” was stated (related posts). The “so that” was obvious (to discover more content). The template would have added words without adding information.
The Squirrel, naturally, heard “related posts” and proposed eight sprints of vector embeddings, knowledge graphs, and A/B testing frameworks. The Lizard heard “related posts” and added See Also links from the existing wiki-link graph.
The User Story template would not have prevented the Squirrel’s proposal. No template can prevent enthusiasm. But the template would have added a layer of formality that made the Squirrel’s eight-sprint plan look reasonable, because it would have been expressed in the same format as the actual requirement.
The Index Card
The User Story’s original medium — the index card — was its best feature. An index card is physically small. You cannot write an epic on an index card. You cannot write acceptance criteria, implementation notes, technical constraints, and a link to the Figma mockup on an index card. The index card enforces brevity through physics.
JIRA tickets have no physical constraint. A JIRA User Story can contain thousands of words, dozens of acceptance criteria, embedded images, linked documents, and a comment thread longer than the implementation. The index card became a wiki page. The conversation became the comment thread. The reminder to talk became a substitute for talking.
The User Story format survived the transition from card to ticket. The User Story’s purpose did not.
