Skip to content

In my classes, whenever I share that User Stories is not part of Scrum but comes from another Agile Framework: Extreme Programming XP, my students are very surprised. So I thought I will share what I know about User Stories and a few things to keep in mind when creating a User Story.


3Cs of User Stories:

Sharing an extract from Ron Jefferies’ blog that I thought has been pivotal to the better understanding of the essence of the User Stories.

Essential XP: Card, Conversation, Confirmation

Aug 30, 2001 (extracted from User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.


User stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement, and to remind everyone what the story is. The card is a token representing the requirement. It’s used in planning. Notes are written on it, reflecting priority and cost.


The requirement itself is communicated from customer to programmers through

conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated (usually during release planning), and again at the iteration planning meeting when the story is scheduled for implementation. The conversation is largely verbal, but can be supplemented with documents. The best supplements are examples; the best examples are executable, We call these examples confirmation.


No matter how much discussion or how much documentation we produce, we can’t be as certain as we need to be about what is to be done. The third C in the user story’s key aspects adds confirmation that we sorely need. This component is the acceptance test.

At the beginning of the iteration, the customer communicates to the programmers what she wants, by telling them how she will confirm that they’ve done what is needed. She defines the acceptance tests that will be used to show that the story has been implemented correctly.

At the end of the iteration, when the story is done, the programmers show the customer that the story is done, confirming success by showing that the acceptance tests run correctly.

The confirmation provided by the acceptance test is what makes possible the simple approach of card and conversation.


User Stories Format:

Format: As a <type of user>,
I want/need <some function> so that <goal or value>.

Example: As a Video Editor, I want the application to automatically save my file every few minutes so that I have multiple versions of my project to reference if I need to revert to a prior version.

The Who, What and Why are really important aspects and so is the acceptance criteria

What is Acceptance Criteria?

The above story example will be complete when the following are true… Some Examples:

•File types?
•Number of Users?
• Peak Transaction Count


INVEST Criteria

When creating User Stories a guideline that really helps is the INVEST criteria

I – Independent (Stories should be independent of each other. They can be sequentially dependent but can be delivered separately and still deliver value to the customer)

N – Negotiable (Stories should be negotiable so that the what is required and the acceptance criteria can be added or removed and still deliver value to the customer)

V – Valuable (Stories should have value from the perspective of the user. It cannot be a technical task or component. It should be a a single feature slice that the user can feel and touch)

E – Estimable (Stories should be estimable, They cannot be so large that we cannot assign a relative estimate value)

S – Small (Stories should be small, something that can be achieved in 2 – 3 days)

T – Testable (Stories should be testable, they should have a rich set of acceptance criteria)

Here are some examples of User Stories that you can download. Watch this space for a future article on splitting user stories.

Did this article help you? What else can we share about stories that will be helpful to you?

Scrum, Product Management, and DevOps: Simplifying the jargon

The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance,, or DevOps Institute, this knowledge is difficult to achieve.

The Concepts & Beyond blog is a free suite of articles and videos packaged in tiny chunks. You will learn or refine your knowledge and skills to help your team and organization be effective. When you want to take your knowledge further, we invite you to join us for our  Certified ScrumMaster(CSM),  Certified Scrum Product Owner (CSPO), Certified DevOps Engineering Foundations (DOEF) and Training from the Back of The Room courses across the USA and Canada.

19 Comment on this post

  1. I think it would be helpful for some advice for finding a balance between having enough acceptance criteria for a user story to match the user’s needs or wants, but not including too much so as to impede the programmer from being creative and finding the best solution.

  2. I think it’s important the ‘conversation’ part needs to be recorded somehow, so everyone has a reference to what was agreed on. It would be useful to have some guidance on how much is too much when it comes to supplements and examples, and what a good level would be – it can be difficult to explain what is needed by the stakeholder without being too prescriptive.

  3. I personally would like more in-depth insight of what qualifies as an Acceptance Criteria i.e. the extent of detail that needs to be included such as the extent of edge cases to be incorporated besides listing the attributes for which feature is to apply.

  4. This is helpful and affirming. I am currently working a project with a high number of user stories and this article has confirmed I have largely used the correct approach, but also provided pointers on how I can make improvements.

  5. The information on the 3 C’s is very helpful. I currently struggle with acceptance criteria and functional requirements. We use acceptance criteria as an overview of what the customer needs, then the functional requirements breakdown the feature/changes step by step. It seems that this causes confusion for the team at times. How can we move away from functional requirements and ensure that we are still delivering what the stakeholders need?

  6. Thanks for your insight Anil. It would definitely help create quality user stories. I would also appreciate if you could share some sample acceptance criteria as well. Thanks again.

  7. I think a reference on your thoughts on Ghekrin Syntax for stories might be interesting & helpful. We have embraced this in our organization of late and are finding fairly pleasant results from it!

  8. The current content is really apt on User stories, however I think it would be helpful if we have a 2 liner about what a user story is in the starting of article and also a question i have in mind is “why do we need user stories”

Join the conversation

Your email address will not be published. Required fields are marked *