The Structure of a User Story
What is a User Story?
In Agile software development, user stories define one or more software features from an end user perspective. In simple terms, user stories are ideas of requirements that convey the needs of a user. A user story can be of one or more sentences and is generally called a “to-do” list. It ensures the process and products created meet the actual requirements of the user.
The specific requirements in the user story will convey:
- When the development team can start and finish development
- When testing team looks over the developed code to check if it meets the actual requirement or not.
- when the Product owner verifies functionalities and confirms that the story is complete, and is therefore considered “done”.
In many organizations, the product owner is responsible for writing user stories and organizing them on the product backlog. In most instances, this is a shared responsibility among the entire cross-functional product team.
Structure of User Story
User stories carry four major parts to outline requirements:
- Role
- Goal
- Benefit
- Acceptance criteria
Sample of user stories such as,
“As a <Role> I want <goal>so that <benefit/expected outcome>”
Acceptance criteria are the conditions that the software product must meet to be accepted by a user, a customer or other system. The Acceptance criteria is essential for a user story to use in development, unit testing and QA.
User stories with 3C’s
A User Story has three primary sections, each of which begin with the letter ‘C’: Card, Conversation, and Confirmation.
Card
Card represents 2–3 sentences used to describe the purpose of the story.
The Card is usually in the following format:
As a <Role> I want <goal>so that <benefit/expected outcome >
The written text must address the “who (role)”, “what (goal)” and “why (benefits)” of the story.
Conversation
The collaborative conversation facilitated by the product owner involves all stakeholders and the team. This conversation is mostly verbal, where detailed description of the user story is discussed. The written Card is modified to reflect the current shared understanding of this conversation.
Confirmation
Confirmation represents the acceptance criteria, which is how the product owner will confirm that the story has been executed to their level of satisfaction. Confirmation represents the conditions of satisfaction.
How to identify the correct User Story
User stories should be recognized together with the stakeholders, ideally through a one-to-one meeting.
- During conversation with stakeholders, the product owner clearly understands and identifies their needs and requirements.
- These needs are then noted down as user stories at the same time.
- These user stories will become the source of requirements.
An Example of a User Story
User story
As a user, I want to sign up to an e-commerce platform so that I can purchase products.
Acceptance Criteria:
- User can sign himself or herself up on the e-commerce site.
- User can visit this e-commerce site.
- User clicks on sign up.
- User provides First name(mandatory), Last name (Optional), email address (mandatory), Phone number (mandatory) and Address (optional).
- System would then ask the user to provide captcha confirmation.
- System would confirm captcha.
- Upon successful sign-up, user should receive a message ‘An email will be sent with an activation link’.
- After successful verification of user’s account, user allowed to create password/secret.
- System should display an error if user tries to enter an email address already registered with platform.
- User must enter first name, last name and email 100 characters long.
- Address field must include ‘Address line’, ‘Country (dropdown menu)’, ‘State (dropdown menu)’, and ‘Zipcode’ fields.
- System should display an error if mandatory information is not provided or if field is left incomplete.
- Password must contain one uppercase letter, one number and one special character(!”#$%&’()*+,-./\|\:;<=>?\@[]^_`\{}~).
- Password length should be 8 to 16 characters.
Thanks for reading! I hope you learnt a bit more about user stories today.
When we come up with an idea or requirement, we try to define the requirement before analyzing that idea on certain feasibility parameters. We discuss more on this crucial aspect of business analysis in our post here:
Author — Sunayana Paikaray, DLT Labs™
About the Author: Sunayana is a Business Analyst at DLT Labs who has completed her Masters of Business Administration in Finance & HR. In her spare time, she loves to dance, sing and indulge in creative activities. She also likes to meditate in her free time.
