Minimum Viable Product Development – Define User Stories – PART 1

Last Updated on: July 10, 2020

The number of Applications in the market has risen significantly, each app trying to outdo the rest. There’s a huge competition and people’s expectations of digital products has only risen. Applications, web apps, websites, any and every digital product just keeps getting more intuitive to use and are provides more delightful experiences than ever. There are obviously some practices and techniques used in order to develop products that the customers love. One such method is creation of Minimum Viable Product (MVP), which helps to understand and create products which keep on incorporating changes according to regular feedback received.  

The goal while creating and developing MVPs is create such a version of the product which is delivered in minimum time possible but still not compromising on the relevance of the product for the target audience. In order to achieve this, it is very crucial and important to define user stories and keep them as point of references for product ideas and its subsequent development.

The process of Minimum Viable Product development or software prototyping should be parallel to updating user stories continuously. Insights from user stories can cut a lot of bottlenecks in the development process of minimum viable products.

Systango conducts a rigorous 3 week long discovery phase before starting the development of MVP characterised by workshops, in which we discuss, brainstorm and internalise everything that is important for the project. There are 2 major steps in discovery for MVP creation –

Step 1: Define Our User Stories
Step 2 : Create user boards and wireframes

In this article we are going to look at the Step 1 of the discovery phase in details. We would talk about creating user boards and wireframes in the next article.

Define Our User Stories

Let’s begin with what is user story?

A User story is a method to add business value by capturing requirements from user perspective in the form of some description.
OR
In the simplest way User story is the form of representation of a small business requirement in the form of description.

Templates:

Why is focusing on user stories better?

Good products now stand synonymous to value that it creates for its customers and users. It is an amalgamation of various features which put together in a cohesive way would create value for its customers. In order to choose the right set of features and to put them together in the correct way, you need to refer user stories.  

Using user stories for creating MVPs is actually working in a reverse chronological order, where we would start with the end result as perceived for the previous products.

Without referring user stories, you might end up developing unnecessary complex features, which the user need in the first place and would in turn increase the delivery time and resource cost for the product.

So how do we create an MVP based on user stories?
Step 1: Pen down all the use stories which you find could be resourceful for the MVP. Remember, each story must capture certain features that add value to the product.
Step 2: Put the user stories in order of their priority and the level of difficulty of execution. The order could be based on the requirement, target market or deadlines.
Step 3 : Looking through user the story selected, find takeaways to use and them as features to your MVP.

Who Writes the user story?

In case of Agile methodology, anyone can write or should write a user story, However Product Owner is “responsible” for making sure that the user stories written for product are based on expectations and managing their backlogs.

Before we dive into writing user story – There are few principles we should understand in order to produce great user stories:

INVEST Principle

INVEST is a nemonic

• Should be independent.
• In traditional approach, you get requirement specification  where requirements are specified clearly however clear separation between requirements is not defined most of the times so that you can prioritise them individually. In software world, some features of the product hold up others or some could be tested only when another is done.
• If user story is not made independent – Then it could hold up on other because of which a situation could arise where the user story would be incomplete.

• A Team should be able to negotiate what is there in a user story.
• In traditional approach – no suggestions were taken from the team. But in Agile, Product Owner with the help of team members decides what is going to be there in a user story.

• Any user story should have value associated to it. This way we ensure that whatever features are being added provides an ROI. Features not associated to ROI move to least priority.

• Any user story should be written in such a way that project team could read details and provide estimates on it.

• User stories are generally kept small of upto a day or two so that when it’s done, it quickly adds value to the system.

• A piece of functionality in the user story should be testable independently.

3Cs

Card, Conversation and Confirmation

Card – In case of agile to keep things simple – Stories are written on cards along with Acceptance criteria and Edge cases (Usually you also use cards in JIRA for writing story line and its description for Acceptance criteria, Edge Cases)

Conversations – In the traditional approach , FRS is prepared, handed over to team members. Team then does implementation and atlast presents it to the product owner. This approach makes a lot of room for the mistakes ,features being misunderstood incorrectly and the product owner realises it all at the end. Now with user stories – It’s not only just to document the requirements – It forms the basis of any discussion and conversation between the team members, product owner and stakeholders.

Confirmations – While conversations take place, the team gets to a point where they build increment of the product as per specification – The QA team confirms that its built as expected.

Now, let’s get to the part where we write a User stories?

Generally, a User story is written on 3*5 inch card.

We need to keep in Mind the concept of 3 Rs here.
Example of User Story

As a <Role>
I want <Requirement/Goal>
so that <Reason/ROI (return on investment)>

• Role – Refers to the type of user who has the requirement
• Requirement – refers to the goal user type wants to achieve
• ROI – Refers to the value if will give to user and therefore to the business

Example of Facebook Login in Mobile app
As a Facebook user I want to Login so that I can be connected on my social network.

If the user story speaks by itself the third R that is Reason/ROI could be skipped.

Acceptance Criteria?
The purpose of Acceptance criteria is to articulate precisely when the user story is done from product owners perspective to produce acceptance tests.

Quality Assurance Team should refer to it to write acceptance tests to confirm if the user story is actually right. It’s the product owner’s responsibility to verify if acceptance criteria covers what’s been expected to call a user story as done.

Example Template of writing acceptance criteria which I usually follow:
As a <Role> I should be able to:

• <AC 1>
• <AC 2>
• <AC 3>
• etc

Example of writing Acceptance Criteria
As a Facebook user I should be able to:

• See Login screen with username and password and a login button
• Login to Facebook account with correct credentials
• See error message if entered incorrect credentials
• etc

EDGE CASES:
It’s not necessary to write these, but in my experience it helps to identify or discuss most tricky situations/conditions to be handled in user stories

Example of writing edge cases
As a <Role> I should be able to:

• <EC 1>
• <EC 2>
• <EC3>
• etc

As a Facebook user I should be able to

• See error message if internet goes off instead of app getting crashed or throwing me out of the app

What are Epics?
Epic

• A large Story
• Which cannot be completed in one sprint or iteration

Example of Epic
As a WhatsApp user I want to be able to communicate with my WhatsApp contact

This has two major aspects i.e. ways in which I could communicate

• I can chat with my contact
• I can do audio recording and send to my contact

Even after doing an extensive discovery phase, at times we uncover a few requirements once the project begins and the app starts taking shape. During the development phase, a few things uncover which makes the user story large and which cannot be completed in a sprint and hence needs to be splitted into various user stories.
And that’s why at the start of every project a user story is considered as an epic.

Why we write user stories at Systango:

• Helps reduce documentation
• Needs less administration
• Leads to continuous customer collaboration
• Easy to give estimations
• Simple prioritisation
• Team contribution to enhance or implement feature in right direction keeping technical feasibility in consideration

Here are a few tips we suggest for writing good user stories:

And well, if the entire process is too much for you to do on your own, then we would love to step in and help you out.

At Systango, we give appropriate amount of time and effort to devise user stories and create corresponding wireframes that form the pillars of our entire product (MVP) that we deliver to you. We believe this groundwork is the secret to delivering awesome products with continuous and rigorous improvement. Contact Systango today for web and mobile app product development services.