“User Stories” with Simple example

User Stories are very common in the Agile and Scrum world. However, User Stories are not part of core Scrum. User Stories are part of Extreme Programming, a different framework under the Agile umbrella. Functionality briefly explained in the format of a story from an end user point of view is called a User Story. Every User Story contains a small value associated with it to the end user. User story is a pointer to the requirement, which will be discussed further to get required details. User story tells how someone uses the Product.

User story has a simple format as given below:

AS A <USer role> [Describes who is interacting with the Product]

I WANT <Action> [Describes what does the user want to do with the Product]

SO THAT <Benefit> [Describes why does the user want to do the action]

Example:

AS A <Facebook user>

I WANT TO <Register to XYZ.COM using my Facebook ID>

SO THAT <I can replicate my profile details easily to create profile in XYZ.COM website>

User Story comprises of 3 Cs:

Card: A simple description written on a small 3 by 3 post it note just contains the above format

Conversation: Because the description is very high level, it leads to a conversation to get more details. Usually this conversation happens between the Product owner and the Development team in Product Backlog Refinement (PBR) or in the Sprint Planning. It may also happen sometimes between the Product owner and the Stakeholders. User stories are invitations to conversations.

Confirmation: Based on the conversation the Development team and the Product owner comes to an agreement on the conditions of satisfaction (aka acceptance criteria).

How to write Good User Stories?

When you write User Stories, make sure to satisfy the “INVEST” principle in order to make them good User Stories.

Independent: As much as you can, make each User Story a stand alone so that it can be released faster

Negotiable: User stories are not contractual agreements between Product owner and Development team. There should be scope for negotiation

Valuable: User stories should contains business value to the end user (it can be small value also)

Estimable: User stories should have enough details so that the team can come up with confident estimates

Sized appropriately (Small): Small User stories can be completed faster and helps to receive early feedback

Testable: User stories should have proper information related to completeness.

What is Acceptance criteria?

Acceptance Tests are the conditions of satisfaction for the User Story. The Acceptance Criteria describes the “completeness” of the User Story. When the Development Team implements the User Story in a Sprint, they develop and test the code based on the Acceptance Criteria. Product Owner uses the Acceptance Criteria in order to accept the User Story upon implementation completed.

Make sure the consider SAFE criteria in order to create better Acceptance Tests:

Success: Criteria for success for the User Story

Advance: Any pre-conditions to be satisfied as part of the User Story

Failure: Details to describe the failure conditions

Error: Details to describe the error conditions

Task Vs User Story:

Tasks are the implementation steps to convert a User Story into a working software. Tasks are created by the Development Team during the Sprint Planning for the User Story. Task is a technical activity to achieve the functionality which is User Story. Example Tasks are: Create a new database table, create user interface, Write an API to validate Facebook authentication, Perform functional testing and so on. These tasks are usually added to the Sprint Backlog so that the Development Team can organize their work by executing them during the Sprint.

User Story Lifecycle:    

The User Story lifecycle is purely tool-specific. Different tools use different lifecycle stages for the User Stories. Below are the general steps involved in a User Story lifecycle:

New → Ready → In Progress → Ready for Testing → Tested → Approved — Completed

New: The Story is created and may/may not have all the details

Ready: Team and Product Owner discussed the User Story and it is estimated. It is ready to be pulled into a Sprint

In Progress: The User Story is in a Sprint and work is in progress

Ready for Testing: User story development is completed, unit testing done and waiting for the tester to validate.

Tested: User Story testing completed, if any bugs identified, they are fixed and it is now ready for the Product Owner’s testing and approval

Approved: Product Owner testing is done and it has been approved

Completed: User Story is deployed into the Production and end users started accessing the functionality of the User Story.

Let us write a few User Stories taking WhatsApp “Calls” section.

User Stories for the above functionality:

• As a Whatsapp user I want to see all the call logs of my whatsapp calls so that I can review them based on the need

• As a whatsapp user I want to be able to differentiate missed calls from all calls so that I can have a quick view of what did I miss

• As a whatsapp user I want to be able to place a new call so that I can communicate with my contacts based on the need

• As a whatsapp user I should be able to delete the calls from the call list so that I can keep the list up-to-date

• As a whatsapp user I want to see a photo of the contact for every line item in my call list so that I can recognize the person more easily

• As a whatsapp user I want to see the number of calls made by a user so that I can identify the urgent calls to be attended

• As a whats app user I should be able to differentiate incoming and outgoing calls for the calls in my call list

• As a whatsapp users I want to see the details of a call from my call list so that I can find more information related to that call

• As a whatsapp user I want to see the call date in the call list so that I can find who has tried calling me on what day/date

• As a whatsapp user I want to be able to call the person/number directly from my call list so that I can easily reach out to them