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 http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/) User stories have three critical aspects. We can call these Card, Conversation, and Confirmation.
Card
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.
Conversation
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.
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:
•Constraints?
•Size?
•Geographies?
•File types?
•Colors?
•Speed?
•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, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.
Helpful.
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.
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.
Thank you, It would be nice to have some links to other resources you think will be helpful around user stories.
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.
Nice Article. Cleared most of the doubts about the user stories.
Concept is very clearly described
Really informative!
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.
We really struggle with writing user stories so this guidance is really helpful
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?
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.
Thank you for your feedback. I have added a pdf to this article with examples of user stories.
Informative article. I think it would be helpful to have some user story examples.
Hi Dalton,
Thank you for your suggestion. I added a downloadable pdf of example user stories. Hope this is helpful
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!
Thank you Brian! You just inspired me to write about how I teach Gherkin and ATDD. Let me add it and send you when I am done. We will also discuss in the class
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”
Thank you for the valuable feedback, I will add those in and will cover them in the class