You have been working on an agile team or maybe a Scrum team. And every time someone refers to requirements, they mention about User Stories. So, now you have started to believe that User Stories are Requirements.
But is that true? Well, the short answer is NO. User Stories are not Requirements. They are one of the many ways to capture requirements. And this is an important point to remember.
Let’s get to the longer answer.
What are Requirements?
In the simplest possible terms, I would state that any need or expectation of a customer, client, user or business that generates a benefit or value for them can be considered as a Requirement. In other words, anything that is REQUIRED to create a VALUABLE and USEFUL PRODUCT can be termed as a REQUIREMENT.
Requirements often help to determine the WHAT and HOW in the realm of Product Development. Diving deeper and paying close attention to the needs and expectations of customers to describe the Requirements can also lead to understanding the WHY behind it.
Requirements are usually classified into different categories - Functional, Non-functional, Technical and Business.
· Functional Requirements: Describe what the system should do (e.g., take payments via credit card; allow users to login using MFA).
· Non-Functional Requirements: Describe how the system should perform (e.g., performance, security, usability).
· Technical Requirements: Detail the technical specifications for implementation (e.g., For MFA, an OTP should be generated; OTP has to be numeric, 6 digits, needs to be sent over SMS).
· Business Requirements: Outline the business needs and objectives(e.g., Make user authentication more secure)
What are User Stories?
User Stories originated in Extreme Programming.Since their advent they have become synonymous with Requirements specially for agile teams. And many folks consider that User Stories are Requirements. However, there is a subtle difference. User Stories are not Requirements, but at the very best they are an approach to express the requirements of the customers. To put it more simply, an User Story describes a functionality that will be valuable to its User.
Example: A customer can make payments using credit cards.
Kent Beck, in his book describes that User Stories are an antidote to requirements which are often mandatory and get in the way of being adaptable.
The idea behind User Story
User Stories are considered as an invitation to conversation not a fixed contract of scope. The aforementioned one liner user story is a great example of a conversation starter. It just has minimal yet sufficient information for Developers to start asking questions about the functionality desired.
As more folks started using XP, User Stories got their current syntax. It was created by Rachel Davis at Connextra and it implies that there has to be an user persona which needs some functionality to receive some benefit.
An example:
As a customer
I want to make payments using credit card
So that I can purchase a product
Ron Jeffries went on to add some more clarification to the structure of user stories; he describes that a User Story should follow the concept of 3C’s. Card; Conversation; and Confirmation.
Card:
A minimalistic but sufficient information describing the need of the customer. This card is written in a 3 sentence format establishing a persona of the user, their expectations and the value they will get as mentioned in the example earlier. This is expressed by a customer in a business oriented or customer focused language keeping the technical jargon out.
There is also another syntax which came a little later in usage. Chris Matts is accredited to the creation of this syntax. This new syntax asserts that the value created is most important aspect and hence should be the first statement of the user story. Thus, our earlier example can now be rewritten as:
In order to purchase a product
As a Customer
I want to make payments using credit card
Conversation:
The user stories described using the syntax, leads to a conversation. A conversation to create a shared understanding between the customer and the developers. This conversation revolves around the details of the requirement.
As an example for the earlier Card story, developers may ask questions like:
- Which credit card to support - Mastercard, Visa, Amex, any other card?
- Do we store the card information or not?
- Would there be an option to buy now and pay later, on the credit card.
- And more…
As the conversation continues a shared understanding is created between the developers and the customer/Product Owner. This shared understanding is termed as confirmation.
Confirmation:
When the Developers and Customer/Product Owner create a shared understanding about what needs to be done in order to achieve the desired benefit from the feature/functionality that is termed as the confirmation. Most often these details establish a way to determine when the story can be treated as complete. This confirmation is also known as Acceptance Criteria and drives the creation of acceptance tests.
Example: In case of the earlier mentioned User Story
1. The customer should provide a valid master card
2. Expiry date on the card has to be provided
3. CVV number on the card has to be provided
4. If expiry date is not in future, throw error message
5. If CVV is not provided throw error message
6. If the card number is less than 12 digits throw error message
Once the Card, Conversation and Confirmation is completed we have a basic user story in place. In order to make it even better, it is recommended to follow Bill Wake’s INVEST model where INVEST means Independent, Negotiable, Valuable, Estimable, Small and Testable.
What are other approaches to formulate requirements?
Not all requirements can be expressed in the form of User Story since not all requirements originate from the user perspective. There might be many needs which might originate within the development process, some from the workflow, while others might originate from system requirements.
Some other approaches to capture requirements include:
1. Use Case and Scenarios:
This is used to describe the interaction between the user (or other systems) and the product under consideration to achieve a specific goal. This usually focuses on the user interacts with the system.
2. Specification by Example
This method focuses on providing concrete examples of the expected behaviour of the system. Behaviour Driven Development which uses languages like Gherkin to define executable instructions is a great tool to convey user specifications as well as acceptance tests.
3. Prototyping
Another great approach to establish clarity of customer expectations or system behaviour is to create prototype. These prototypes could be basic low-fi like paper prototypes or could be interactive hi-fi using tools like mural, miro or figma.
4. Context Diagrams/Mind Maps
A context diagram or mind-map enables developers and the customer/Product Owner to visualize a high level diagram of the product. It also helps to establish how the system interacts with various other components that could be external to it.
5. Data Modelling
This is more suitable to define the various data objects, their attributes and relationships with the entire system. Typically the databases, the storage models, integrity of the system can be derived from this.
Conclusion:
Often practices are given more importance over the principles and it leads to misunderstandings. It is important to acknowledge that User Story is one of the many ways to capture User Requirements and it works because it is founded on the basics of conversation. Remember, it is not the full requirement but it is merely a conversation starter to gain a better and shared understanding of requirements. Let’s not force fit user stories where they are not required and use them as a placeholder for conversation where they can create the most impact.
P.S. At Agilemania, my partners and I often debunk such common misunderstandings. If you are interested to learn more, you are most welcome to join our newsletter, follow and subscribe our youtube channels @piyushrahate and @agilemania or visit our website www.agilemania.com to check the courses we offer.