How To Write Awesome User Stories?
In Software engineering, requirements gathering has multiple techniques. User stories are one of the most popular techniques in agile development. It's a way to document stakeholders' requirements in an informal manner. The primary focus of a user story, is talking about requirements value rather than writing a detailed specification of each functionality. Basically, a user story is a short statement mentioning the potential value that a specific stakeholder believes he/she would achieve from the solution/system. In addition, user stories are always complemented with Acceptance Criteria. Those criteria verify that the proposed designed solution is meeting the stakeholders' objectives.
This article is describing the components of a user story as well as giving tips to write a good user story.
What is a User Story?
In a nutshell, a user story is a statement describing a feature from the perspective of a specific user of the system. Actually, user stories have the following template:
As a <system user - persona>, I want to <goal - feature>, so that I <reason - business value>
Example: As an anonymous user, I want to create an account on xyz platform, so that I can register as a contributor or subscriber.
Definitely, handing a user story like the above to the dev team is not explanatory enough. It's missing the most important part of a user story which is, Acceptance Criteria, in addition to Edge Cases.
What are User Acceptance Criteria?
Acceptance Criteria is a set of conditions that need to be met, in order to fulfil the user goal. This is where the product owners collaborate with the developers and the QA team to brainstorm on the different conditions. Acceptance Criteria should be covering both perspectives; business and technical.
Example: As an anonymous user, I want to create an account on xyz platform, so that I can register as a contributor or subscriber.
Acceptance Criteria:
- User can create an account by entering the following data:
- First Name, Text
- Last Name, Text
- Email, Text (email format)
- Password, Password
- There is a bar showing the user password strength based on the following:
- 30% - red – letters
- 60% - yellow – letters & numbers
- 90% - green – letters, numbers & symbols
- Upon submission, user should be notified by receiving an email containing a link to activate the account.
What is an Edge Case?
Edge Cases are defining the alternative scenarios for the user story. That is, what could go wrong with the feature? That is where the product owner is helping developers handling exceptions that may result from the feature.
Example:
As an anonymous user, I want to create an account on xyz platform, so that I can register as a contributor or subscriber.
Edge Cases:
- If the user has not filled one of the required fields, the platform should notifies the user with the missing values.
- If the user is trying to create an account with an existing email, the platform should notified the user with the option to log in using the existing email or request reset password.
Top 5 Tips for a good user story
- INVEST Checklist
- A good user story is:
- Independent: It can be implemented in any sequence based on prioritization and arrangement of other user stories. It can be moved up or down the backlog, yet, it can be developed as it’s shippable on its own.
- Negotiable: Product Owners should avoid adding detailed information in the body of the user story. This type of information can be modified until meeting customer expectation. Therefore, it should be mentioned in the acceptance criteria.
- Valuable: What is the business value behind developing this user story? There should be an answer to the question or else there is no point from it.
- Estimable: The team should be able to judge if the user story is small/medium/large or extra-large as they will use it planning the backlog then later when breaking down the tasks in sprint planning.
- Small: The smaller the user story, the more focus it will get from the team. It would be easier to estimate, break it down to tasks and deliver it.
- Testable: Providing the conditions that could identify how the story should be tested is crucial for a story to be done; and that is what we defined above in the acceptance criteria.
- Independent: It can be implemented in any sequence based on prioritization and arrangement of other user stories. It can be moved up or down the backlog, yet, it can be developed as it’s shippable on its own.
- A good user story is:
- Epics are good for a start
An epic is a large user story that can be broken into smaller user stories using the checklist defined above. Epics are high-level features or headlines in the system; they can be easily defined in the early stage of product backlog creation. Then, they can be broken down over sprints.
Example: As an anonymous user, I want to learn about xyz platform.
Description: This user story is concerned with the fact that we will have an “About” page in the platform, it was then broken to the following user stories:- As an anonymous user, I want to read an overview about the portal.
- As an anonymous user, I want to know the objectives of the platform.
- As an anonymous user, I want to know more about the Customer Due Diligence Process in the platform.
- Acceptance Criteria key success factor to done definition
Providing clear conditions that describe how the user story will be done from the perspective of the customer or the product owner, is essential for the team to develop it. Quality team use these criteria to generate test cases; so they need to detailed and concise.
- Business Value should be there
Having the business value in the user story body is debatable in some cases. However, it plays an important role in explaining to the team why is this user story a feature to the customer and what does he want to achieve with? Adding the purpose of the story brings up a healthy discussion of “I don’t believe that the <want to …< part fulfils the <so that I…> part. This is where we face the challenge of implementing what the customer wants not what he needs.
Example: As a subscriber user, I want to view product trade information so that I can decide on which product to invest.
What the user wants?
View Product Trade Information
What does he need?
Take an investment decision based on product trading data
Implementing what the user wants may result into page listing each product trading details. On the other side, knowing the added value to the user, may result in implementing comparison of products trade information using data visualization that may help the user to take his investment decision.
- Acceptance Criteria ONLY are not enough
We need to enrich our user stories acceptance criteria with workflow diagrams, storyboards, wireframes, mockups or other techniques in order to visualize the product functionality. To be able to create a great user experience (UX), product owners need to support user stories with visual design techniques as part of the user story acceptance criteria.
Actually, those techniques play an important role in clarifying the written criteria especially when the end product is a portal or website, they ensure consistency of the design across the pages.
Reference:
https://www.mountaingoatsoftware.com/agile/user-stories
http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
https://sprint.ly/blog/agile-user-stories/
https://www.alexandercowan.com/best-agile-user-story/
.webp)
.webp)
