What are User Stories
A User Story is a short description of a requirement used to describe a valuable feature of the software or the user. It clearly and succinctly communicates the functionality that the user wants.
It is used to describe the user's needs from the user's point of view and is used as one of the ways to express the user's needs.
It explains the results users expect from their perspective. The user story clearly explains the value that the new feature provides to the user, rather than just focusing on the functionality.
It is also a medium for program developers, product managers, and stakeholders to communicate about requirements.
The Three Elements of a User Story
A user story is a way to describe a user's needs, what are the components of a user story?
It generally consists of 3 elements:
- Role (who): Who uses it.
- Activity (what): What activities are to be accomplished. What functionality does the system provide?
- Value: Why do you do it? What value is provided. What value does it bring to the user? What business value is generated? What business objectives are being achieved?
As a <character>, I want to <complete activities> in order to <achieve purpose/realize value>.
What user stories contain
The above is a short overview of the elements that go into a user story. The book Agile Software Development: User Stories in Action describes 3 aspects of a user story:
- A written description of a story.
- Conversations about the story are used to flesh out the details of the story. In order to get the details of the user's story, it is necessary to communicate and talk to the person concerned to get the details of the story.
- A test that records story details and is used to verify that the story is complete.
Describe user story content with cards
What tool can be used to quickly and easily describe and record user stories accurately? A: Card recording.
For the description of user stories, another person, Ron Jeffries, succinctly summarized the three aspects of user stories in the previous section in three words, as follows:
- Card
- Conversation.
- Confirmation
The Card contains a textual summary of the user's story, and the details of the requirements need to be obtained during the Conversation, recorded and verified during the Confirmation session.
Card
On the card is a short description of the user story, the rules, and the acceptance criteria for completion.
- The front of the card is written with a three element description of the user's story in the format:
As a <character>, I want to <complete activities> in order to <realize value>.
Example:
As a salesperson operating a back office, I want to consolidate sales data from different sources so that I can easily analyze sales data and create sales reports.
- Under the card write the rules and completion acceptance criteria for user stories in the format:
Given...When...Then, give the user a xxx function to use in xxx situations at xxx times, then xxx (success/failure/error)
A simple example:
Scenario: A user logs into a software system with a cell phone number and authentication code.
- Given: The user logs into the system with a cell phone number.
- When: When I enter my cell phone number on the screen, then click on Get Verification Code and enter the verification code to log into the system.
- Then: The correct verification code was entered and successfully logged into the system.
(story cards)
The story card contains a short description of the user story, some rules and acceptance criteria for completion. The details of the user story, and some of the details will need to be obtained by talking to the people involved.
Presenting with physical cards, rather than hypothetical ideas, helps team members discuss the needs together.
Conversation
The source of detail for the user stories is communication with users/customers, product stakeholders, conversational conversations with all stakeholders, and understanding based on the conversations to organize the requirements. It is then necessary to ensure that all parties are aligned in their understanding of the user story.
This is actually how to dig into the details and details of the user's needs, and communicating with the user/customer to talk to them is one of them.
The second stage of the user story, how to fulfill the requirements on the card and to understand the details of the requirements, needs to be obtained by discussing and asking questions with the user/customer and the people involved in the product.
Confirmation
Acceptance tests are used to confirm that each user story has been completed correctly.
Example of acceptance test format:
Generally it is the validation of operational business rules. For example, validating the user login system function:
1. Under the condition of entering the wrong cell phone number, the xxx error message will appear, and as a result, the login fails.
2、In the case of timeout of the verification code input, there will be xxx prompts, resulting in login failure.
3, test input expired cell phone number, will appear xxx prompt, the result of login failure.
Some testing methods: 1. Functional testing (unit testing) 2. Interaction testing (integration testing) 3. Automation testing (continuous delivery testing) 4. Performance testing (stress testing)
Six Characteristics of a Good Story INVEST
Six Characteristics of a Good Story INVEST, which consists of six initials:
-
Independent: Each user story should be independent of each other, and dependencies between stories should be avoided as much as possible. Dependencies between stories can lead to problems with prioritization and planning, and can also make estimation difficult.
-
Negotiable: The story is negotiable, it is not a requirement that the software must fulfill, it is just a short description of the requirement, and the story details (requirement details) are output during the communication phase of the conversation.
-
Valuable to users or customers: Ensure that the story is valuable to the user or customer, and that the story must be written from the user's or customer's perspective. This is usually not easy to do but try to do it.
-
Estimatable: Estimate the size of the User Story that needs to be developed, or give a User Story to a developer, the amount of work needed to implement the code for the User Story, and how long it will take to develop it.
-
Small: A good user story can't be too big or too small. A story that is too big is called an Epic, and an Epic should be split into smaller stories. So how do you judge the size of a good story? One criterion is that it can be completed in at least one iteration or Sprint. A story that is too big is a big risk in terms of workload estimation.
-
Testable: User stories are small, specific, and testable. If the story is too vague to be tested, how can it be validated?
How to write user stories
How do you write effective user stories and where do you start?
target user
What are the target users of the product that need to be identified and defined in order to write effective user stories? Who will use the software product and how will they interact with it?
Define user needs
After identifying the users who will use the product, it is important to dig into the goals that the users want to achieve by using the product.
That is, what do users want to get out of using the product, what do they expect from the product, what do users want?
This step is about tapping into the real needs of the user.
Product Features
Once you have clarified the user needs, you have to think about what kind of features the product can provide? Can meet the user needs.
There's another important step in this step, theCompetitive Analysis。
Or think about an important question: why do users choose us over our competitors?
Receiving and Inspection Criteria
The team develops and delivers the product and needs to accept that the user stories are being completed and fit the criteria.
Several validation criteria can be listed for each user story.
consultation
- User Stories and Agile Methods/subject/4743056/ Author: Mike Cohn