User stories - Card, conversation and confirmation [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

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

Answer 1

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

• Change should be returned if the customer does not put in enough money and then selects a beverage

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.

Answer 2

You can do whatever you want ;), from writing down everything to memorizing everything and writing nothing. Personally I write everything down, so the next dev that picks up the story can understand as much as I do and pick up from there.