1

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

Montag451
  • 1,168
  • 3
  • 14
  • 30
Fabrizio Duroni
  • 747
  • 1
  • 11
  • 24
  • I'm voting to close this question as off-topic because the question is not about programming. It's about UX design. Would be better in https://ux.stackexchange.com/ – stone Dec 01 '17 at 22:41

2 Answers2

2

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.

will webster
  • 574
  • 5
  • 11
  • So following your answer what I'm supposed to do is write down the card part with the format "AS A (ROLE) I WANT TO (DESCRIPTION) SO THAT (DEFINITION)". Another question regarding my example above: you've made an example of a user story focused on the refund. Don't you think that this part could be a bulled on the back of a card instead of an entire new user story? (was it only an example or you want to show me that I'm not doing things in the right way if i write a user story related to the entire process of beverage purchase?) – Fabrizio Duroni Oct 20 '13 at 10:04
  • It is really up to you and your team how you break down the User Stories. Use the INVEST principles as a guide. Make sure you break down and groom the backlog as a team and in the presence of the product owner. This is where all the magic happens (the conversations). You will find people have a variety of ideas on how to break down a set of requirements. – will webster Oct 20 '13 at 11:42
  • To expand a bit on Will's comment about the card being a 'placeholder for a discussion', I see cards as a starting point. You take the card/story, you have your discussion, and the output of that is a set of Acceptance Critera which ultimately define the requirements. If you can fit those criteria on the back of the card, great. If not, you could either split the story into multiple smaller stories, or simply store the criteria somewhere else. – thecodefish Oct 21 '13 at 03:09
0

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.

Nicolas Straub
  • 3,381
  • 6
  • 21
  • 42