This article is part of the Effective User Stories Series.
If you’ve missed reading Part I: Why User Stories, we strongly recommend you check it out first.
User Stories are the de-facto standard for describing user needs. Almost every Agile Team uses them but they often struggle to define them.
Writing a good User Story is not an easy task.
As we discussed in the previous article, one reason is that people are not always aware of the User Stories’ purpose. Many project managers tend to believe that a User Story is the Agile Way of calling the documentation. A User Story is more than just a requirements management technique to run Agile projects.
Remember:
User Stories are not requirements.
To write effective User Stories, first, you need to know what a User Story is.
What is a User Story?
The easiest way to explain what User Stories are is to take a look into the “Three Cs” (Card, Conversation, Confirmation) defined by Ron Jeffries, one of the three people who originated the extreme programming process.
Card
The first C stands for a “card” (“a notecard”, to be specific), which is the traditional way of writing User Stories. By using cards, we are limited to the amount of space that can be used, so we cannot add too much information.
It is very important to understand that the card IS NOT a requirement. We shouldn’t think of User Stories as requirements.
We should think about them as a pointer to the actual requirement.
The real specification of what needs to be done might be elaborated in a conversation or a different document, such as a workflow diagram, a math algorithm, UI design, and so on.
Another advantage of using cards is that they are super easy to create. Every team member should be creating many User Stories throughout the product development process. Besides, they can be easily torn into pieces or deleted if no longer needed (even if that is just a few days after writing them).
Conversation
The conversation is probably the most important part of the three Cs.
Business and technical people often struggle to understand each other as the two groups speak in different languages – business and technical. User Stories solve that issue by establishing a common language that all parties understand and speak – the language of the customer or “the User”.
The card should be considered as a promise for the Agile Team (PO, SM, developers) to have a conversation about a specific user need. The team “promises” to have that conversation before starting to work on the Story. It gives them the freedom not to write and define every last detail down on the card. The requirements behind the User Story will emerge during the conversation and the team might or might not write them down elsewhere.
Confirmation
All the clarifications during the conversation are used to define the Conditions of Satisfaction or Acceptance Criteria.
Conditions of Satisfaction are the things that the Team expects to be fulfilled once the User Story is “Done”. It needs to be a short and clear list of items. Also, they can be considered as a script for the Sprint Review event.
By design, the User Story should be small. It is said to be small enough to be fully delivered during a Sprint and our guidance is to be small enough to be fully delivered within a couple of days.
If you end up defining too many Acceptance Criteria for the Story, it has likely become too big and needs splitting into smaller User Stories.
One benefit of having smaller User Stories is the increased Team Motivation. There’s a great satisfaction for the team when the Story is marked as “completed”.
The opposite is also valid. When the team fails to complete all Acceptance Criteria despite the hard work during the iteration, they won’t get any credit and might get frustrated.
Always Mind the Three Cs
It is crucial to have the three C’s in mind when working with User Stories.
Always remember – they are not the requirements but a tool to discover them collectively.
The next post will answer How to Write User Stories?
We will give you practical knowledge and techniques that you can use to improve the quality of your User Stories.
