User Stories and the Acronyms to Help Develop Good Ones-EN

User stories are representations of requirements, elaborated in one or two sentences and collected in a common language that is easy for the user to understand. Also known as simply US, they have become a standard for defining requirements. Although their popularity comes from Scrum, they are actually NOT a standardized element in the Scrum Guide. In many organizations, user stories are even considered a synonym for a requirement (in the same way that some call a delivery “MVP” or a classic project manager “PO” without changing their functions).

User stories first appeared in Xtreme Programming (1999), but were popularized by Mike Cohn in his 2004 book: “User Stories Applied: For Agile Software Development“. In the book, he sets the simple three-part pattern for defining them:

• As a <type of user> or <person who expresses a need>
• I want/need <a goal>
• So that <a reason> or <value obtained>

In this article, I am not going to expand on the reason for writing a user story, if it’s better or worse than another format, the possible anti-patterns, or the misuses. Instead, I am going to review a few acronyms and mnemonic rules that can help you create good user stories that contribute to achieving end-to-end quality. That is, from the beginning, from the definition of requirements. 

Don’t forget that requirements are the raw material on which the entire subsequent process is based. I don’t even think I need to tell you, but… the last thing anyone wants to do is base their project on a defective or poor quality foundation.

The 3 Cs

The “3 Cs” is a simple rule with an even simpler definition. Every user story must meet these three criteria:

• Card: Your definition should be short enough to fit on a card. Martin Fowler even mentions ideal measurements. The definition of a user story should simple enough to avoid the need for unnecessary explanation.
• Conversation: As a consequence of Card, a user story is an opportunity for dialogue between those who express the need and those who satisfy it (in Scrum, between the PO and the development team). An overly detailed story creates a false sense of completion (“It’s all in the definition,”) and avoids much-needed conversation to align those involved.
• Confirmation: At the same time, even in its brevity, the user story must contain the necessary elements to determine that the value sought by the need has been delivered. And if you do not have them, the Conversation will help them to emerge as acceptance criteria.

My colleague Jacqueline thinks this rule is missing a C – Context! For more on this and the 3Cs, she her The 3 C’s of User Stories are Missing a C article.

INVEST

INVEST is series of basic criteria to build quality user stories. Each criterion is necessary to build the foundation for a quality product. This rule, defined by Bill Wake, recommends that each US be:

• Independent: or with minimum dependency on other user stories. This facilitates the ability to execute user stories in any order, since dependency naturally determines order and also tends to become a risk.
• Negotiable: the details of user story construction emerge from a conversation (one of the 3 C’s) between the person who expresses the need and the person that carries it out.
• Valuable: or with value. In other words, the result of the user story adds value to its users. In this sense, we must be aware that the concept of value can be very broad.
• Estimable: there is sufficient information to be able to guess the effort necessary to execute the user story.
• Small: the user story should not require more than a certain amount of time to be built. In teams that apply Scrum, it is common to use the convention that a story must be able to be completed during the course of a Sprint. If not, it needs to be divided. Fragmenting large user stories into smaller components is a delicate action for which other techniques can help.
• Testable: the user story contains information to make it possible to validate that the story fulfills its mission through tests or evaluations. This often requires incorporating additional information in the form of acceptance criteria, which define and clarify the scope of what you expect the story to accomplish.

The INVEST criteria are a great tool for determining the quality of the requirements.

The Four Rs

This lesser known model describes the stages through which a need becomes a user story and ultimately delivers value. Being aware of the stages is a way of understanding the evolution that all requirements go through and the actions and agents involved in each step. The Four Rs are:

• Raw: the “raw” idea, the story is still a bit hazy and has not been completely clarified.
• Rough: it is “enough” of an idea to identify stakeholders, value, reasons, and initial acceptance criteria.
• Refined: it has been sufficiently worked and is approaching reality. Not only has the necessary information been completed, but the user story has been prioritized and estimated. 
• Ready: all the groundwork work is done and the story can be executed. This is the final step before becoming part of the product sprint.

There are also alternative versions in a slightly different order.

DEEP

Although this primarily refers to backlog content (in particular, to the Scrum product backlog), the DEEP criteria can be helpful in managing user stories as well since they make up the backlog. DEEP stands for:

• Detailed (appropriately): the level of detail will be relative to its state. For example, a raw US requires much less detail than one in the Ready state. There is also no point in investing effort prematurely if the story never makes it out of the Raw state.
• Estimated (appropriately): since throughout its evolution the estimate can range from very rough[KA1]  to more refined.
• Emergent: the elements of the backlog (such as the user stories) are constantly evolving. The backlog is never static; items are always emerging and being refined, deleted, completed, re-prioritized, changed, etc.
• Prioritized: the backlog must follow some kind of ranking order which affects the user stories contained in it.

User Stories are Everywhere

User stories can be used outside of agile frameworks and software development to help ensure a task or goal is well understood and is manageable. They can also help us understand how to know if the task is done or the goal is achieved. All of the acronyms above can be used in any context… just think about applying the criteria above to:

• Help manage a large to-do list
• Organize and track a personal project, like setting up a home office
• Plan a family vacation

Example story for personal use:

As a parent, I need to manage my work using user stories so that I can spend more time with my family.

User stories are a very useful tool if they are built and managed properly. I hope using these acronyms and rules can be as helpful for you as they are for me.

— Alonso