Traditional projects had requirements in the form of work breakdown structure which were written as features (Ex: login feature, search feature). With this type of requirement writing, development teams wrote code while keeping in mind the specifications written by the business analyst. However, a single project had multiple personas involved with each likely to use the same feature for a different purpose. Let’s take an example of a search feature, insights like who is searching, why are they searching and what they are searching would change the way the feature needs to be built tremendously.
The key shift in the way requirements are written now is to try and explore answering these three basic questions:
- Who is asking for the requirement?
- Why are they asking for the requirement?
- How will they use the requirement?
This blog aims at understanding a concept in agile ways of working called “User Story” and the way we write requirements in an agile environment keeping customer centricity in mind. We will attempt to understand more about:
- What are user stories? What is a user story template?
- Why and How to write user stories?
- What are some of the user story examples?
- What is a user story template example?
- How to work with user stories?
- What is meant by a user story template acceptance criteria?
- How to write a user story with acceptance criteria?
- What is a user story template for agile development?
- What are examples of user story template with acceptance criteria?
We have captured these and other aspects of user stories based on our experience as an agile transformation company in this blog.
What are agile user stories?
A User Story is a simple/brief one-line requirement written in simple language from a customer/end user’s point of view. The whole purpose of a user story is that the requirement should talk about the end user, demand, and purpose. User stories strongly promote some of the main agile principles like delivering value to the end user and conversations within the team.
A user story should –
- Always have a business value
- Help teams get feedback from the users
- Trigger a conversation
- Be usable to the end-user when delivered
- Be an increment to your product
A user story is written in plain simple, non-technical language which when read, tells the team who wants the requirement, why they want and what they want. The intention behind the requirements and the core of agile principles strongly influence the purpose of writing a requirement with a user story template.
3C technique provides an end-to-end flow of a user story with the help of a user story template and is widely used. What is 3C?
- Card – A physical representation of a user story. A Post-it where the statement is written
- Conversation – The team discusses the requirement, ideates on it, explores solutions and approaches to build it together
- Confirmation – The team then converts the requirement into a plan of action by answering the size of the work, when to work on it etc
What is the Structure of a User Story?
A user story is a simple statement from the end user’s perspective. It talks about what the user wants and why. A user story structure helps the teams and stakeholders to understand the user needs, concentrate on delivering value, and verify the work that meets the end-user goals. A user story also comes with acceptance criteria.
A typical user story has 3 parts or components it and a user story template goes like this,
- Summary / Title – A brief description of the feature or functionality
- User story template / Narrative – As a <Persona> , I want <Demand>, so that <Purpose>
- Persona – the role of a person or a group of people who will benefit
- Demand – What is that the user wants to accomplish
- Purpose – Why does the user want the requirement? What is the value it generates with the requirement?
- Acceptance Criteria – All the specific conditions that must be met for the story to be considered done. These criteria ensure that the feature works as intended and gives the team adequate details to solve and test.
A user story template example is shown below in the image.
User story template acceptance criteria
Why create user stories?
User story is a crucial part of agile ways of working promoting customer centricity which is one of the principles of agile. It ensures the voice of the end user is heard along with the why and what part of it.
Let’s understand this with an example:
Scenario 1: ( Run this exercise in your head )
Imagine you are building a product for your customer and his need is very simple,
He wants to build an automobile to move from point A to point B where he can carry some luggage. Let’s say he gives us the requirements as:
- We need to move from point A to point B with luggage, so we need 4 wheels
- An engine to move the body
- A body with seating capacity and also a small place to carry luggage
- A music system and basic wipers and horn
What did you imagine? Probably a car with boot space right???
Let’s go again!!
Scenario 2:
Imagine you are building a product for the same customer and his need is very simple,
He wants to build an automobile to move from point A to point B where he can carry some luggage. But this time he mentions the users who will use his product “Truck Drivers”
Let’s say he gives us the requirements as
- We need truck drivers to carry goods/luggage from one point to another so we will need bigger wheels
- We will need powerful engines because of the different terrains
- Goods/luggage drop off is the main criterion so place the body accordingly
- A music system and basic wipers and horn
What did you imagine this time? Probably a truck or pickup truck right??? This is the difference user-centricity brings.
Some of the important aspects of why to even write user stories include:
- End user Centric – User stories ensure that the development process is built around the needs and experiences of the end users. This alignment with user needs helps in creating a product that delivers real value
- Collaboration within the team – They promote better communication among team members and stakeholders by providing a common language and understanding of the requirements. This helps bridge the gap between technical and non-technical team members.
- Helps in incremental Value delivery – By breaking down features into smaller pieces, user stories enable the team to make incremental progress. This approach helps in maintaining momentum and achieving quick wins.
- Improved Quality – User stories often come with acceptance criteria, which define the conditions that must be met for the story to be considered complete. This clarity aids in better testing and ensures that the developed feature meets the desired requirements.
- Fosters better solutioning – Teams take a user story and in the process of understanding it, explore possible solutions and pick the best one to solve the need
- Simple with Clarity – User stories are typically brief and to the point, making them easy to understand and discuss. This simplicity ensures that the team can quickly grasp the requirements without getting bogged down in excessive documentation.
Working with user stories
A User Story is the smallest unit of the work item in agile projects. Working with user stories is a process that involves various stages, from creation to implementation and validation. Here is a guide to work with user stories (user story guide).
- Creating User Stories
- Identify User Roles
- Determine the different types of users or personas who will interact with the system. Example: Customer, Admin, Visitor, Member, etc.
- Gather Requirements
- Conduct interviews, surveys, and workshops with stakeholders and users to gather requirements.
- Understand the pain points, needs, and goals of the users.
- Write User Stories
- Use the user story template example “As a [persona], I want [demand] so that [purpose].”
- Define Acceptance Criteria
- Clearly state the conditions that must be met for the story to be considered complete.
- Identify User Roles
- Refining User Stories
- Backlog Grooming
- Regularly review and prioritize the product backlog with the team.
- Ensure user stories are well-defined, clear, and ready for development.
- Estimate Stories
- Use estimation techniques like Planning Poker or T-shirt sizing to estimate the size required for each story.
- Consider complexity, effort, and dependencies.
- Split Large Stories
- Break down epics or large user stories into smaller, manageable pieces.
- Ensure each story delivers a piece of value and is testable.
- Backlog Grooming
- Prioritizing User Stories
- Value-Based Prioritization
- Prioritize stories based on the value they deliver to the user or business.
- Use frameworks like MoSCoW (Must have, Should have, Could have, Won’t have) or Kano model.
- Dependency Management
- Identify and manage dependencies between stories.
- Ensure that prerequisites are completed before dependent stories are started.
- Value-Based Prioritization
- Developing User Stories
-
- Sprint Planning
- Select user stories for the upcoming sprint based on priority and team capacity.
- Define the sprint goal and ensure it aligns with the selected stories.
- Development
- Encourage collaboration between developers, testers, and product owners.
- Conduct daily stand-ups to discuss progress, blockers, and next steps.
- Continuous Integration and Testing
- Implement continuous integration practices to frequently integrate code changes.
- Write and run automated tests to ensure new features meet acceptance criteria.
- Sprint Planning
- Reviewing and Validating User Stories
-
- Sprint Review
- At the end of the sprint, demonstrate completed user stories to stakeholders.
- Gather feedback and discuss any changes or additional requirements.
- Acceptance Testing
- Validate that the user story meets the acceptance criteria.
- Perform user acceptance testing (UAT) with actual users if possible.
- Sprint Review
User Story Guide
How to write user stories
Writing a good user story involves mentioning the needs of the user and the value they will receive from a feature or functionality. An ideal user story has a simple structure and includes specific components to ensure clarity and completeness. Let’s see how the 3C framework can be applied in writing a user story:
- Card – A physical representation of a user story. A Post-it where the statement is written
- Define the user story – Use the standard user story template “As a <Persona>, I want <Demand>, so that <Purpose>
- Persona – Identify who the user role is. This could be a specific type of user or group of users.
- Demand – Describe what the user wants to achieve or what feature they need.
- Purpose – Explain why the user wants to achieve this goal or how it benefits them.
- Adding Acceptance Criteria – Acceptance criteria specify the conditions that must be met for the user story to be considered complete. They provide clear guidelines for what needs to be done and ensure that the feature meets the user’s needs.
- Define the user story – Use the standard user story template “As a <Persona>, I want <Demand>, so that <Purpose>
- Conversation – The conversation refers to the discussions between the product owner, stakeholders, developers, and testers about the details of the user story.
- Clarify the requirements, understand the context, and explore the details of the user story. This interaction helps in aligning everyone’s understanding and setting expectations.
- Discuss the user story in backlog refinement sessions or sprint planning meetings.
- Engage in collaborative discussions to explore different approaches and potential solutions.
- Confirmation – Confirmation involves defining the acceptance criteria for the user story. These criteria specify the conditions that must be met for the story to be considered complete and acceptable.
- Ensure that the story delivers the expected value and meets the user’s needs. Acceptance criteria provide a clear definition of done and guide testing efforts.
- List down conditions or scenarios.
- Estimate the story and prioritize
Writing a good user story is a skill that comes with practice. Here is a very effective framework to consider while writing an effective user story.
Framework to write an effective user story
User story template and examples
A user story template is very simple and precise. A standard user story template with an example is “As a <Persona>, I want <Demand>, so that <Purpose>. Different teams follow different user story template for agile development based on:
- How they are grouped
- What information do they need
Some of the user story template for agile development with acceptance criteria examples include:
- Standard User story template – This is the simplest user story template with acceptance criteria and could be used as a starting point. All basic elements of the user story are captured along with the priority, estimate, and title.
- User story template grouped by themes or epics – This template helps teams and stakeholders get a sense of which epic/ strategic theme the user story belongs to
User Story Examples
- E-Commerce
- Story – As a customer, I want to search for a product, so that I can buy it
- Acceptance Criteria –
- 5 search results must be displayed
- Search results must be auto-suggested
- Search results must not take more than 2 seconds
- Banking
- Story – As a user, I want to be able to transfer funds between my accounts so that I can manage my money more effectively
- Acceptance Criteria –
- All my current accounts must be displayed
- Accounts added must be displayed in “To”
- Decimals and special characters should be rejected
- The transfer must happen within 3-5 seconds
- Healthcare
- Story – As a patient, I want to receive appointment reminders via SMS so that I don’t miss my appointments.
- Acceptance Criteria –
- 1st reminder must be sent 3 days before the appointment
- 2nd reminder must be sent 1 day before the appointment
- SMS should contain a feedback link
- SMS should contain all the appointment details
- E-Learning
- Story – As a student, I want to be able to track my progress in each course so that I can see what I have completed and what is still pending.
- Acceptance Criteria –
- Progress must be updated immediately once the course is completed
- Progress must be shown in percentage
- All subject progress must be visible
Getting started with Agile user stories
User story writing for agile development definitely could use an ideology of starting somewhere and then improving it/ iterating it until it becomes a habit. Here is a glimpse of where you can start your journey of writing user stories:
- Understand the Basics of User Stories – What are user stories, what are the principles of writing a user story, advantages and disadvantages
- Identify User Roles – Determine who your product users are. Different roles might have different needs and goals. Examples of user roles include Admin, Consumer, Guest, etc
- Gather Requirements – Engage with stakeholders and users to understand their needs, pain points, and goals with the help of workshops, interviews, surveys, observations, etc
- Write user Stories – Take a simple user story, start small, focus on value generation use the INVEST framework
- Define Acceptance Criteria – Write down all the necessary conditions on which the stories can be marked complete
- Showcase the difference – Make this a habit and bring in the user story in your workflow. Prepare the product backlog, start with refinement sessions, prioritization, estimations, slicing techniques, and validations in a review meeting
- Manage the user stories using a tool – Use tools like JIRA, Asana, AHA, etc to manage your user stories
- Make adjustments and improvements – Based on your company culture and product needs, make recommendations and adjust
Conclusion
User stories are a basic component of an agile project and the smallest unit of work, providing a clear, simple, and user-centric way to write requirements. By following a structured approach to writing and managing user stories, teams can ensure they stay focused on delivering value to users and stakeholders.
This blog has covered the process of identifying user roles, gathering requirements, writing user stories, defining acceptance criteria, and incorporating user stories into your agile workflow in our experience as an agile consulting company. These practices ensure better communication, collaboration, and clarity within your team. Remember, user stories are supposed to be simple, and trigger conversations between people. As you continue to refine your approach to user stories, keep the user’s perspective at the forefront, prioritize based on value, and maintain flexibility to adapt to changing needs and feedback.
With this, our blog on “User Story Template – A step-by-step guide” comes to an end and we hope this blog has helped you understand user stories and how to start, write, manage, and validate them. For any feedback or suggestions please feel free to write to consult@benzne.com.
Frequently Asked Questions
1. What is an epic and user story in Agile?
An Epic is a big unit of work that is too large to be done all at once. It is broken down into smaller, more manageable tasks called “user stories.” Think of an epic as a large goal, and the user stories are the steps needed to achieve that goal. By breaking down an epic into smaller pieces, teams can work on and complete parts of it over time, making the work more manageable and allowing for regular progress checks.
A user story is a simple statement from the end user’s perspective. It talks about what the user wants and why. A user story structure helps the teams and stakeholders to understand the user needs, concentrate on delivering value, and verify the work that meets the end-user goals. A user story also comes with acceptance criteria.
2. What is a user story in Scrum?
A user story is a simple statement from the end user’s perspective. It talks about what the user wants and why. A user story structure helps the teams and stakeholders to understand the user needs, concentrate on delivering value, and verify the work that meets the end-user goals. A user story also comes with acceptance criteria. We have shared user story template acceptance criteria example in this blog to help you write simple and effective user stories.
3. Why is it called a user story?
A “user story” is called a user story because it is written from the perspective of the end-user or customer. It describes a feature or functionality in terms of how it will provide value to the user. The format typically includes who the user is, what they want to do, and why they want to do it. This approach helps to keep the focus on delivering value and ensuring that the development work aligns with the user’s needs and goals.
4. What is the lifecycle of a user story?
Below is a typical user story lifecycle:
- Write User Stories: Create user stories using the Role-Action-Benefit template. Ensure that each story is concise and focused on a single feature or piece of functionality.
- Review and Refine: Regularly review and refine user stories in backlog grooming sessions. Ensure stories are clear, detailed, and prioritized based on business value and urgency.
- Estimation: Estimate the effort required to complete each user story. This can be done using techniques like story points, planning poker, or t-shirt sizing.
- Sprint Planning: During sprint planning, select user stories to be worked on in the upcoming sprint. Break down user stories into smaller tasks if needed.
- Development and Testing: The development team works on implementing the user stories, ensuring they meet the acceptance criteria. Conduct testing to verify that the story functions as expected.
- Review and Acceptance: At the end of the sprint, review the completed user stories with stakeholders. If the acceptance criteria are met, the story is considered done.
5. What is the user story technique?
The user story technique is a method used in Agile software development to capture and describe features or functionalities from the perspective of the end user. This technique focuses on understanding and articulating what the user needs and why, ensuring that the development team builds software that delivers real value. Utilize the user story template example mentioned in this blog to write effective and simple user stories.
Nice content