Having worked in multiple teams, I have come to realize that every one seem to have a different understanding of agile principles and methodology. Their perception of agile methodologies is mainly formed from their previous experiences (esp. at the companies where they do not have any certified agile coach). This has led to many difficult conversations and endless discussions about how exactly Agile Development should work. One of the hot topics is of course: User Stories. So I thought I should write down what the user stories are from my perspective. Below is an attempt to answer some basic questions related to them.

What are user stories ?

User stories have their origins from the days of xtreme programming (XP) where they were one of the game pieces of the planning game. In a sense, user stories are an agile way to writing functional requirements. They inform the developers/engineers about what the system should do as against how the technical solution should look like. They are not be misunderstood as requirement documents but rather a collaborative tool which takes shape as and when more information is available from various stakeholders. Consider it as a tool that encompasses all the knowledge that is required for the product version A to become a version A’.

Why use user stories ?

Since the user stories are lightweight, the whole idea for a user story is to start a conversation around the story. Such conversation and collaboration allows every stakeholder to get involved in the solution building and thus brings a mutual understanding of what we are building and what value we are adding.  The way user stories are written helps the team to understand the real intention of the user when interacting with the product and thus fosters innovative ways of building solutions. As opposed to requirements documents which are detailed in technicalities, user stories are deliberately kept at a high level leaving much of the details to be sorted out via conversations with engineers and team.

When to write user stories ?

The creation of ‘User Story’ process shall begin only after you have some kind of qualitative or quantitative information available from your user research, customer discovery processes or with certain data analyses respectively. The reason for this is that instead of just assuming what your view of the user is, you will have sufficient information to back you assumptions up and also it helps to write the user intentions in much better way within the user stories.

Writing user stories should start from the design process itself and should run until the actual development starts. This allows the owner of user stories with ample time and opportunity to update them regularly with new information and details. For designers, it becomes a good conversation starter to explain all the important user actions/use cases that can be done with the system without getting into details of how the solution should look like. They are constantly updated with the grooming sessions that the team has on a regular basis. Grooming sessions are particularly important because this is where the team discusses on how the solution should look like and the Product Owner can add the details as the results of the conversations.

How to write user stories ?

User stories are small and clear by the nature ensuring that they are understood in the same way by everyone. General principle to follow while writing user stories is: INVEST principle.

I = Independent, N = Negotiable, V= Valuable, E= Estimable, S= Small, T= Testable

The user stories should primarily focus on the ‘What’ and ‘Why’ of the problem. They should be written in such a way that anyone in the team reading them should instantly ‘get it‘. Universally accepted format is the below:

As a <persona>, I want to do <what> so that <why>

As you can see the user stories are written from the user’s perspective and how he will interact or what he expects/his goal is from the system to perform certain ‘job to be done‘. They should focus only on the feature and user’s behaviour/flow with the system.

I hope this article has helped to answer the very basic questions about user stories that should be universal everywhere.