What are User Stories in Agile? Writing examples and templates explained are explained.
When developing a product, there are two perspectives as below;
- User perspective (customer: business perspective)
- Making perspective (development side: technical point of view)
If development proceeds only from the making point of view, there is a danger that product development will be carried out that is easy for the developer to make, ignoring the needs of the customer.
Making user stories will make it possible to develop products that value not only the perspective of the development side, but also the customer’s perspective.
A user story shows how the product you develop is useful (provides value) to a user (or a specific persona). User stories are an important point in order to avoid the mistake of ignoring the customer’s needs and creating what the developer wants to create.
Agile development, which repeats sprints, is suitable for development that can respond to user stories in which conversations and opinions are exchanged with customers, rather than conventional waterfall development.
By reading this article, I think you will be able to comprehensively understand agile development that emphasizes user stories.
What you can learn from this article
What is a user story
A user story is a short sentence that describes a feature or service you develop from the point of view of a user (or a specific persona).
User stories describe the types of users, what they want, and why. User stories help create short descriptions of requirements.
User story definition
What is a user story
・Who needs the product?
・What users (or specific personas) want?
・What purpose can the developed product achieve?
These requirements are defined from the user’s (or specific persona’s) point of view and summarized in easy-to-understand words that anyone can understand.
- As [ persona ]
- I can [ Feature]
- so that [ passionate why ]
User stories write about “features” and discuss “why do we need them?”
User stories are the starting point for conversations to establish real-world product requirements .
The purpose
The purpose of creating a user story is to express in an easy-to-understand manner what kind of end-needs the functions of the developed product provide to users (or specific personas) and what kind of value they provide .
For that reason, it needs to be created in plain language as much as possible without using technical terms so that customers can understand it.
Who creates it?
User stories are generally created by people who are in a position close to the customer’s needs, such as product owners, project managers, and UX designers, who can make decisions from a more diverse perspective from the customer’s point of view. However, creating it with all team members will progress undestanding further.
Benefits of using user stories
Advantage 1: Providing better value
User stories help you deliver the best value by focusing on the needs of your customers or specific personas on a small scale.
Advantage 2: Promotion of collaborations
Development members and product owners discuss user stories before they start working on the implementation of user stories and after they are completed.
These discussions may add diverse business and technical perspectives to find creative and innovative ways to solve customer needs.
Advantage 3: Optimize product components
The product is built step by step, with each customer value providing a user story. Building your product in stages allows for rapid implementation and feedback.
Successful implementation of each feature will form a product that will continue to grow in value.
Advantage 4: Increase transparency
User stories are typically shared with teams and stakeholders. This increases transparency between team members and stakeholders, enabling better collaboration and faster decision making.
Advantage 5: Shared understanding
Product owners and development members work together to create and improve user stories to improve common understanding.
“Who (users, customers, or specific personas)” “expects”, which is “what can be achieved” from a technology and business perspective, what the product owner intends, and the development team understands what to implement
Advantage 6: Risk Reduction
Increasing transparency, improving collaboration, and creating shared understanding can lead to a variety of risk mitigations. For example, it reduces a variety of potential risks, including communication risk, technology risk, and business risk.
Why user stories go well with agile development
In agile it is important to “frequently provide working (usable) items” .
User stories serve as the foundation upon which the work to enable this frequent release is built.
Creating user stories also helps the team understand the key points of the project and helps organize tasks around sprint planning and prioritization.
User stories break down complex tasks into smaller pieces, making projects more manageable and motivating your team.
User story templates and how to write them
Remember that user stories are more about the discussion that ensues than the actual content of the story. However, using a template is probably the first step in creating user stories.
User story template
As [ persona ]
I can [ Feature ]
so that [ passionate why ]
Because it can be done with “function” as “persona”
So, “reasons to be excited, value to be gained.”
User Story Guidelines|INVEST
User stories should be independent and non-overlapping so that they can be scheduled arbitrarily.
User stories are created while discussing and negotiating between the customer, who is the end user, and the development team. Also, user stories should be negotiable, not feature promises.
A user story should be written with value for the user.
Identifying your users (or specific personas) helps you think about value as well as working size. This makes prioritization easier.
It is desirable that the size of the user story is equivalent to one to two weeks of work. If the size is difficult to estimate accurately, divide it into smaller sizes to make it easier to grasp and make an accurate estimate.
End-users (or specific personas) should be able to check if a user story is being fulfilled.
User story writing flow
User stories are easy to create if you write them according to the six items of INVEST mentioned earlier.
Let’s write down the following three points:
Set persona
Before developing a feature or service, it is important to think about “for whom” .
Users aren’t the only thing that’s important for a product to grow with great business value. Personas in each category may have different desired functions.
For example, consider categories such as:
Purchaser: Pays money
User: enjoy the product
Influencer/Influencer: Recommend to buy
Stakeholder: Investors, engineers, bosses, etc.
Maintenance: User Support
Auditer: Approve use
Agile Team: Developer, PO, SM
Confirmation of needs | How does the product help end users?
Familiarize yourself with why each persona needs to use the development feature, or the value they get from using it.
A “feature” describes how a persona uses a feature, service, program, system, etc. For example, let’s say you have an app that allows customers to book a gym. With the app it looks like this:
・Users can use the app to search for nearby gyms.
・You can find a gym you want to go to and make a reservation and payment.
・The gym will receive the reservation once the user completes payment.
They show you how to use the app and what you can do with it.
User stories should not only be about what can be done, but also about the “why” .
By knowing why your personas need certain features, you can better understand how your users are using your app and what value they are getting from your app .
・As a user, you can search for a nearby gym, so you can easily go to the gym on the go
・As a user, you can complete payment, so you can reduce wasted time and spend more time using the gym
・Reservation payment can be confirmed, so office work can be reduced and staff can be reduced.
Clarification of purpose
A user story is about articulating how the feature you are developing provides value from a persona’s perspective.
User stories show “who (persona)” wants “what (function or service)” and “why (value)”.
This helps the team understand why they are doing the work and what value it creates.
It helps you prioritize what to build next and what not to build because you understand the value to your persona.
Tell me, Joe! What is the difference between epics and user stories?
The image is as below.
Epic is popular if you use the tool Jira.
Normally,
A user story is a product backlog,
a task (subtask) is a sprint backlog
It is an image that will become
Epic: A larger feature containing multiple user stories.
User Stories: Break up your epics, each offering something testable and valuable.
Task: no value to the user. It’s technical and invisible from the outside.
Subtask: The work that must be done to implement the task.
summary
Scrum typically uses the Product Backlog.
A product backlog is a list of features or services to be developed. There is no set formula for writing this Product Backlog item, but User Stories are the best and most popular form of Product Backlog item.
And the biggest advantage of user stories is that they generate discussions from a business perspective and a technical perspective between teams .
It helps us build better products and, in turn, better teams.
コメント