What are User Stories?
By Anil Jaising Published On October 27, 2021
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.
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.
October 28, 2021 at 9:42 am
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.
October 28, 2021 at 11:06 am
Thank you, It would be nice to have some links to other resources you think will be helpful around user stories.
October 28, 2021 at 11:20 am
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.
October 28, 2021 at 11:37 am
Nice Article. Cleared most of the doubts about the user stories.
October 28, 2021 at 12:35 pm
Concept is very clearly described
October 28, 2021 at 1:07 pm
Really informative!
19 Comments
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.