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 fulfill 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 learn about xyz platform.
Tips for Writing Good User Stories
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.
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 fulfills 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.
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.