How to write a User Story for B4S Process

Hi all,

As an Agile company, we’ve already been familiar with the concept of a user story. However, writing a “good” user story is an art that I am still trying to master and improve every day.

In this post, I will share some of the key points about how to write a user story and points that make a good user story for B4S customization estimation purpose. The knowledge in this post is mostly based on my own research and working experience as a BA in the Earth team. You’re very welcome to contribute your ideas to this topic, too :wink:

1. What is a User story?
User story is an Agile framework used to identify & clarify customer requirements. User stories should be simple and independent from each other. An user story should contain enough information for the dev team to come up with an estimation of the coding hours needed to develop each story.

2. What are the components of a User story
First, let’s take a look at the example below. The example was taken from a real B4S estimation case.

Here are the components of this user story

Component Description
ID The ID number of the user story. For example: US01,US02. The ID number must be a unique value
Description/ Story Card The story card describes the content of the user story. Normally the story card follows this format: As [Actor], I want to [Goal/Need] so that [Why]
Scope The scope of the user story. For instance, sometimes the customer wants to build a feature only for the offline channel (POS), but other features on both online and offline channels.
Assumption/ Condition Conditons/ assumption in which the solution/estimation is based on. For instance, for an 3rd party software integration to Magestore POS, a condition can be that the API document of the 3rd party software is available
Acceptance criteria A set of predefined requirements that must be met in order to mark a user story complete. Acceptance criteria is used to define the boundary of a user story, help the PO understands the value of the user story and help the team share the understanding of the user story.
Acceptance criteria normally includes
Functional requirements: Requirements that are related to the system functionality, what the system must be able to perform.
Non-functional requirements: requirements that are used to judge the operation of a system, rather than specific behaviors. Non-functional requirements are system attributes, like security, reliability, maintainability, usability, scalability, UX,UI. They can also be the contraints/restriction in the design of the system. For example, the feature should run properly on both online & offline mode on POS, or should the form generated follow a specific format?

3. What is a good user story?

A good user story should be able to meet the following criteria

  1. Correct: The user story should correctly describe the requirement of the customer
  2. Adequate: The user story should cover all the aspects (functional & non-functional) and all possible scenario of the requirement. This criteria, indeed, is the most difficult to evaluate. If the acceptance criteria are not properly defined, it may lead to an increase in the scope and cost and a delay in the schedule of the project
  3. Feasible: A user story should be completed within a sprint (1-week). If it takes more than 1 week to be done, consider to break it down to smaller user stories
  4. Testable: the user story should be clear enough so that the tester can develop the test cases and test against the acceptance criteria.

4. What are the technique to write a user story?
People may have very different approach to write a user story. However, here are some common method that can help you gain an idea of how to write your user story

  1. Workflow: Identity the flow of the business process and create stories for the steps in the flow
  2. Happy path: Given the customer workflow, create a story when everything goes well, and other stories when the steps don’t go according to the plan (alternative flows)
  3. Business rules: Many user stories involves explicit and implicit business rules. Breaking each rule into a user story
  4. Operations: Some user stories may involve some default operation (eg: add/edit/remove data from the grid)
  5. Core and enhancement: Define the core feature of the story first, and then add on details to improve the quality of the story

I hope it helps :wink: Let us know if you have other cool ideas on how to write better user stories