Introduction to User Stories #
Generally, for any software development project, the requirements are specified using the following 2 formats depending on the SDLC method followed to develop the software:
- Waterfall Method: Software Requirements Specification (SRS) document
- Agile Method: User Story
In the Waterfall Method, a Software Requirements Specification (SRS) document focuses more on the “Functionality” (What) and “Solution” (How) rather than “User” (Who) and “Value” (Why). Most of the time, it has contractual obligations that make it more rigid.
Because of this, it often fails to deliver “Value” to the “User” or simply put, it’s not user-centric.
To solve this problem, the Agile method emphasized “Working Software” and “Customer Collaboration”, and introduced a better way of specifying requirements in the form of “User Stories” to make it user-centric and to ensure that the software delivers the expected value to its users.
It doesn’t mean that the SRS document is completely obsolete. It is still being used for fixed-price projects and projects where the requirements are fully clear before the development begins. But the point is that, the SRS document should be user-centric. We can certainly create a user-centric SRS document by specifying the functional requirements in the form of User Stories and Acceptance Criteria. Take a look at the following article that explains the importance of strong SRS with templates and examples.
User Stories are essential components of an Agile Software Development project to capture the product requirements or functionalities from the user’s perspective.
A User Story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder (user).
Role of User Stories in Agile Project #
User Stories are decompositions of large requirements (work items) called ‘Epics’.
An ‘Initiative’ is broken down into multiple Epics (large work items), Epics are broken down into multiple User Stories, and User Stories are broken down into multiple Sub Tasks as shown in the following diagram.
A User Story is a small individual work item of an Agile Project and is added to the Product Backlog.
Benefits of User Stories #
- Improves communication by facilitating interaction and collaboration between stakeholders
- Drives creative solutions by encouraging the team to think creatively about how best the value can be delivered
- Creates momentum by delivering incremental value to the working software on completing each user story
- Provides a mechanism for the Product Owner to Scope, Co-ordinate, and Prioritize the increments of Value for delivery
Let’s dive into the specifics of User Stories with Examples and Templates.
The Anatomy of a User Story #
There are 4 elements in a User Story.
-
Title: Describes an activity that the user wants to perform with the system. It’s an Active Verb-goal phrase.
-
Value Statement: A statement with the following 3 information:
- Who: a user role or persona
- What: a necessary action, behavior, feature or quality
- Why: the benefit or value received by the user when the story is implemented
For Example: As a who, I want to what, so that why
As a Buyer, I want to be able to filter products by price so that I can find items within my budget.
-
Conversation: Describe the details of the feature to be developed along with all possible system flows and supporting models such as Use Case Diagram, Activity Diagram, Wireframes etc.
-
Acceptance Criteria: Defines the boundary of a user story and helps the project team (Developers and QA) to understand what solution to provide to deliver value to the user. It may be supplemented with other analysis models as needed.
INVEST Quality Model #
Each user story must fit the INVEST quality model as described below.
- I – Independent: A feature that can be delivered independently of the other features
- Example: “Browsing Products” is independent of “Placing an Order (Checkout)”
- N – Negotiable: It should be possible for the team to negotiate how to deliver
- V – Valuable: Express the value to the user
- Example: Displaying related products at the end of the particular Product helps users to take better buying decisions.
- E – Estimable: The Team can provide an effort estimate to deliver the user story
- S – Sized Appropriately: It should be sized properly in terms of functionality so that it can be included in an iteration. The smaller the better.
- T – Testable: It can be validated (tested) objectively by a stakeholder (user).
Decomposing Epics into User Stories #
Here are the steps to decompose an Epic into user stories.
- Identify and understand the User Personas or User Roles i.e. who are the users interacting with the system, how they do and why.
- Fully understand the Initiative and Epics i.e. why they are undertaken and what value they should provide to the user
- Breakdown each Epic into user stories by following the INVEST quality model.
- Add all the stories (with high-level info) to the Product Backlog and prioritize them with the help of stakeholders
- From the prioritized list of stories, pick up each user story, analyze it and add the details to make it ready for the development team to be able to estimate and include it in the iteration.
User Story Templates and Examples #
Once the high-level stories are created and prioritized, it’s required to elaborate the stories to make them ready for review and development.
Elaborating user stories should be as simple as possible.
It’s advisable to use proven templates to save time in elaborating user stories and make them structured and easy to follow by the stakeholders.
There are 2 most popular templates being followed.
- Simple Template
| Title: | < Requirement / Module Description > |
| As a: | < User > |
| I want: | < System functionality > |
| So that: | < I can achieve the business goal > |
| Conversation: | < Describe the implementation details of the feature such as Pre-Conditions, Field information, Input Validations, Post Conditions, and Reference to the Models such as Use Case Diagram and/or Wireframes/Mockups of User Interface > |
| Assumptions: | < Write assumptions if any > |
| Constraints: | < Write constraints or limitations if any > |
Example:
- Extended Template
| Title: | < Requirement / Module Description > |
| As a: | < User > |
| I want: | < System functionality > |
| So that: | < I can achieve the business goal > |
| Conversation: | < Describe the implementation details of the feature such as Pre-Conditions, Field information, Input Validations, Post Conditions, and Reference to the Models such as Use Case Diagram and/or Wireframes/Mockups of User Interface > |
| User Journey – Normal Flow: | < Mention the Normal Flow of the user interaction steps to achieve the Goal> |
| User Journey – Alternate Flow: | < Mention the Alternate Flow of the user interaction steps to achieve the Goal > |
| Assumptions: | < Write assumptions if any > |
| Constraints: | < Write constraints or limitations if any > |
| Acceptance Criteria: | < Write all acceptance criteria required to complete the functionality which involves all business validations, field validations, input validations, navigation patterns, access controls etc > |
Example:
Bonus: Tips and Best Practices #
User story writing best practices:
- Use active voice.
- Focus on user outcomes, not solutions.
- Keep it concise (avoid long and complex stories).
- Encourage user story collaboration with stakeholders.
Additional Tips:
- Leverage user story writing tools and software.
- Continuously refine and improve your user stories based on feedback.
Conclusion #
Since user stories are an integral part of Agile Software Development, a business analyst should write clear and concise user stories and verify them through the INVEST principle to ensure that the expected value is delivered to the end users.
User Story Templates help a business analyst write effective user stories that convey the requirements correctly with all necessary details and acceptance criteria.