extreme-programminguser-stories

User stories - Card, conversation and confirmation


I don't understand a thing about the Card, Conversation, Confirmation formula for user stories. I don't understand if the conversation and confirmation part must be written down or they remain as a dialogue, in particular the CONVERSATION part. To be clear: is it right if a write down ALL these things in user stories? (see example below) Or do I have to write down only the CARD part?

Example:

CARD As a user of a coffee machine, I want to be able to purchase a beverage.

CONVERSATION - The user will not be able to purchase a beverage if they do not deposit enough money into the CoffeeMaker - A user's money will be returned if there is not enough inventory to make the beverage

CONFIRMATION 1 user introduces the amount of money needed to purchase the beverage 2 user selects the beverage 3 user gets the beverage


Solution

  • The 3 C's is a saying used to serve as a reminder on what is important when using User Stories.

    A simple card to write down the requirements - as opposed to a heavy weight document.

    Having a conversation - collaborating to define the requirements and understand the value.

    Confirmation - agreeing on the acceptance criteria, so you know when you are done.

    There is another saying which sums up the idea behind User Stories nicely. "The card is a place holder for a conversation". This highlights that the conversation is the important part, not the card artifact. The card can be discarded once the feature has been developed and automation tests written using any suitable acceptable criteria.

    The format of a User Story will typically follow:

    As a (role) - This can be an end user or a business proxy
    
    I want - A description of what need to be done
    
    So that - the definition of the value
    

    An attempt at your scenario

    As a vending machine customer
    
    I want my change returned 
    
    So that I do not loose my money
    

    The confirmation part could just be bullet points on the back

    Or you can use the context specification style, a BDD (Business Driven Development) technique

    Given a customer does not put in enough money
    When they select a beverage
    Then their change should be returned
    

    If you would like to know more I would suggest researching the INVEST principles and reading Mike Cohn's User Stories Applied.