User Stories

User stories aren't requirements documents. They're placeholders for conversations.

Ron Jeffries captured this as the "3 Cs":

Card: A brief description that fits on an index card. "As a user, I want to reset my password so I can regain access to my account."

Conversation: The dialogue between developers and customers that fleshes out the details. What does "reset" mean? Email link? SMS code? Security questions?

Confirmation: The acceptance criteria that tell you when the story is done. "Given a valid email, when I click 'reset password', then I receive an email with a reset link within 1 minute."

The card is not the requirement. The conversation is the requirement. The card is just a reminder to have the conversation.

The classic story format is:

As a [type of user] I want [some capability] So that [business value]

For example:

• As a shopper, I want to filter products by price so that I can find items in my budget.
• As an admin, I want to export user data to CSV so that I can analyze trends in Excel.
• As a guest, I want to check out without creating an account so that I can buy quickly.

The "so that" clause is crucial. It explains why the feature matters. This helps developers make good decisions about implementation and helps product owners prioritize.

Bad stories omit the why:

• "As a user, I want a blue button." (Why? What does it do?)
• "Implement search functionality." (For whom? What value?)

Good stories connect features to value:

• "As a returning customer, I want to reorder my last purchase so that I can buy again without searching."

The INVEST acronym describes qualities of good stories:

Independent: Stories can be developed in any order. No dependencies between stories.

Negotiable: The scope is flexible. Details are negotiated through conversation.

Valuable: Each story delivers value to users. No "technical stories" without user benefit.

Estimable: The team can estimate how big it is. If not, the story needs clarification or splitting.

Small: A story should take less than a week of work. Ideally a few days.

Testable: There are clear acceptance criteria. You can verify when it's done.

When a story violates INVEST, fix it:

• Dependent stories: Combine them or break the dependency
• Large stories: Split into smaller pieces
• Unestimable stories: Spike first to reduce uncertainty
• Untestable stories: Clarify the acceptance criteria

Large stories need to be split. But how?

Split by workflow step: "User can complete checkout" →

• User can add items to cart
• User can enter shipping address
• User can enter payment info
• User can confirm and place order

Split by data variation: "User can pay for order" →

• User can pay with credit card
• User can pay with PayPal
• User can pay with gift card

Split by operation: "User can manage their profile" →

• User can view their profile
• User can edit their name
• User can change their email
• User can delete their account

Split by performance: "Search returns results quickly" →

• Search returns results (any speed)
• Search returns results in under 2 seconds

Each split story should be independently deployable. If you can't deploy partial credit card support (only Visa, not Mastercard), that's still a split—you deliver value incrementally.

This is worth repeating: stories are not specifications.

Traditional requirements documents try to specify every detail up front. This fails because:

• You can't know all the details before you start
• Written documents are interpreted differently by different readers
• Specifications get outdated as understanding changes
• They discourage conversation

Stories embrace uncertainty. The card captures the intent. The conversation fills in details just in time. The confirmation verifies understanding.

The customer stays involved throughout. When developers have questions, they ask the customer—not the document. This keeps the team aligned and adapts to learning.

Stories also encourage deferring decisions. You don't have to decide every edge case up front. Handle the main path first. When you encounter an edge case, have a conversation then.

This is XP's approach to requirements: just enough, just in time, through conversation.