"As a shopper, I want to save my payment method so that I can check out faster next time." That is a user story. It is a sentence, not a specification. Agile software teams write them on index cards or sticky notes. The format forces the writer to name a role, a goal, and a reason. It keeps the focus on the person who will actually use the feature, not on the database schema.

User stories were popularized by Kent Beck and Ron Jeffries in the late 1990s. They are deliberately incomplete. The card is a promise for a conversation. Developers, designers, and product managers talk through the details. Acceptance criteria are added later. A story that is too big is called an epic. A story that is too vague is a bug waiting to happen.

Three Cs

• Card: the written story, short enough to fit on paper.
• Conversation: the discussion that fills in the gaps.
• Confirmation: the tests that prove it works.

Good stories are independent, negotiable, valuable, estimable, small, and testable. The acronym is INVEST. It is not a religion. Some teams write stories as job stories: "When I am running late, I want to pay with one tap, so I don't miss my train." Same idea, different frame.