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.
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:
•Number of Users?
• Peak Transaction Count
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.