Things to consider while writing User-stories for productive development

In the last blog we discussed what is Agile Methodology and how it is helping startups to work in an organised manner. One of the core component of the methodology being User Stories; illustrates how the tasks should be defined in order to keep a track of the development process. A survey conducted by KPMG shows that eight out of ten organizations have started their Agile transformation journey within the last 3 years.

However, before adopting the technology or hiring a tech company that works on the Agile Methodology, it is important for you as a prospective adopter to understand how to write user-stories. Let’s understand it with the following steps:

Step 1: Consider the “Who”

The first and the foremost step before writing a user story is deciding the end customer of the product. On top of that always be clear about the needs that your customer has which you are trying to fulfil.

It is important that rather than referring the customer as a “user” while writing your user stories, you identify and name their persona. The term “user” can be applied to a varied number of people and it doesn’t actually reflect the personality of your target group.

At Akeo, we try to narrow down the user persona instead of targeting masses with the user stories. This helps us in having a clear vision of how the customer will behave with the product. Having a clear vision helps us in building a great product.

Here are a few more tips from our own experience:

• Customer should be at the core – It is not about the developers neither about the product owner, a user story should always keep the end customer in mind.
• Understand the product owner’s vision –  User stories are always about end customer but is equally important to understand the Product owner vision behind it. It will help to focus on the USP of the product being built.
• Keep some empathy towards the user- While defining the user persona, you need to think of their habits, their lifestyle, how your product fits into it. A simple association that your form with your user will help create product above par.

Step 2: Think of the “What”

Now we have a few groups of end users. The next step we do is define what functionality each user expects, how he’s going to interact with the app.

These are the main rules to remember when writing an action for a Kanban or Scrum User Story:

• One action per a Story – If you want to write something like “as a customer I want to browse menu items and add them to the cart” you’d better split it into 2 separate Stories.
• Describe an intention, not a feature – For example, instead of “I want to manage my profile” create a few Stories like “I want to be able to register”, “I want to upload my profile photo”, “I want to link my credit card to my profile” – each Story will have a different value.
• Keep it short. The end customer isn’t going to delve into the technical details while browsing your application, so it is better not to mention it here in user stories also. 
• Avoid illustrating the UI – Even though well defined, user stories are always negotiable right. So, try not to put in the User Interface of the service here. They can be built on according to the preference of the product owner. However, do mention the tasks as user stories in order to see progress.

Step 3: Answer the “Why”

For every user story that needs to be created, it is important to know the ‘why’. It may not seem like a big deal but then the ‘why’ defines the metrics and KPIs.

In terms of a user story, the ‘why’ is defined under the ‘so that’ section. In the longer run, the why also helps to increase the retention rate of the user.  

However, your [so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product.

If you can’t answer what value this feature brings to end users and your product as well, then you’re doing something wrong.

For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project:

• As a customer, I aim to get notifications of the discount offers so that I don’t miss out on the best deals. [how it is affecting the KPIs: user gets notified ➡️ they use the app more often ➡️ the retention rate goes high].

• As a restaurant owner, I want to enhance a dish description in the menu with a photo so, that it looks more attractive to the customers. [how it affects metrics: users are more tempted to order a dish when they see photos ➡️ sales grow ➡️ this leads to increment in revenue].

We are offering a free User story template which you can use to define your user stories and plan your product development better.

Step 4: “Retrospect” – It is always healthy

Finally, At Akeo we always retrospect the User Stories after they’ve been completed, even if we faced no challenges while completing them.

It is important to understand what worked or didn’t work for the team while completing a user story. The issues or roadblocks are discussed with the team to help in better performance. Moreover, the next user story tasks or requirements are also discussed for better performance.

A good retrospective session allows us to find out the best ways to implement User Stories from the tech perspective and will also help in refinement.

• Start with what worked –It’s usually better to start the meeting on a positive note and discuss what has been the achievements of the team for a particular user story.
• Understand the roadblocks – It is good to discuss the roadblocks faced by individuals or by the team in the meeting to achieve solutions or find a way to work around them.
• Plan the next week –  It’s better to hold the retrospective session before starting the next to discuss how to implement planned Stories.

We hope we have been able to answer how to take the first step when you are thinking of adopting Agile Methodology. Now, in the next blog we are going to elaborate why we think Agile Methodology is a must-have for ever tech company.

Spread the word!