User Story

A User Story is a simple, structured way to describe what a user wants to do with a product and why. But more than that, a user story is not a requirement, it is a placeholder for a conversation.

As one Agile practitioner famously put it:
"A user story is a promise for a conversation."
The goal is not perfect documentation, but shared understanding.

User stories originated in Extreme Programming (XP) and evolved through real-world practice. In the book User Story Mapping, Jeff Patton reminds us that stories are meant to tell us something about the user, not just the system. A good story focuses on real people using the product to achieve something that matters to them.

That's why the typical format is:
As a [user], I want [something], so that [goal or outcome].

The user in that sentence should be a real end user --- a person who interacts with the product. Not a database. Not a server. Not a developer. Misusing this format to describe internal work or technical tasks takes the focus away from value and creates the illusion of shared understanding, without actually having it.

To avoid that trap, keep in mind the Three Cs model by Ron Jeffries:

• Card -- The user story is written down in short form

• Conversation -- The team discusses what the story really means

• Confirmation -- The team agrees on how they'll know it's done

Or as Steve de Shazer said:
"Understanding does not exist. There are only more or less useful misunderstandings."
User stories help us create the useful kind --- the kind that sparks questions, clears assumptions, and brings teams and users closer together.

Use them wisely, and they'll guide your team not just to build the thing right, but to build the right thing.