User story)

Abstract:

A user uses the system to accomplish a valuable goal (buy a can of drinks. This process is called "User case" or "User Story )". This article describes the agile development skills: How to manage projects with user stories.

What is user story)

Assume that the customer of this project is a manufacturer of beverage vending machines. They asked us to develop a software for their vending machine. We can ask their marketing managers to understand the needs of the software.

Therefore, our customers are their marketing managers. When talking about the demand, he said: "Every coin a user inserts into a vending machine, the vending machine must show how much money the customer has invested. When the user invests enough money to buy a certain drink, the light that represents the drink will be on. If the user presses this button, the vending machine will put a can of drinks to the exit, and then find the change for him ."

The above describes one thing. A user can accomplish a valuable goal (buy a can of drinks) through the system. This process is called "User case" or "User Story )". That is to say, what our customer said above is to describe a user story ).
(I want to explain why the word "story" can be ignored if you are not interested. In the face of a system, every user must fulfill the same goal and perform routine tasks set by the system. This is not an example, so it is not an example, it cannot be a process, but a routine task .)

If we want to write down this user story, we may use the following format:

Name: selling drinks

Event:

1. Users invest some money.

2. the vending machine shows how much money the user has invested.

3. If you invest enough money to buy a certain type of beverage, the corresponding button lights will be on.

4. the user presses a highlighted button.

5. Sell him a can of drinks from the vending machine.

6. Give him the change for the vending machine.

Note that events in a user story can be described as follows:

1. the user performs xx.

2. The system performs yy.

3. the user performs ZZ.

4. The system performs TT.

5 ....

User stories only describe the external BEHAVIORS OF THE SYSTEM

A user story describes the external behaviors of a system in a way that the customer can understand. It completely ignores the internal actions of the system. For example, the following underlined words are system actions that should not appear in the user story:

1. Users invest some money.

2. the vending machine puts the money into the cash box and sends a command to the screen. The screen shows the amount already invested.

3. Check the price of all the drinks in the database for the vending machine and determine which drinks are sufficient for money. For those drinks with sufficient money, the corresponding button lights will be on.

4. Click a highlighted button.

5. the vending machine sells a can of beverage to the user, and then reduces the inventory of the beverage in the database by 1.

6. Change the vending machine to the user.

Whether it is verbal or written, such content is a common error when describing a user story. In particular, do not mention anything about databases, records, fields, or other things that do not mean anything to customers.

Assess release time

What is a user story? Assume that the customer wants to submit the system within 50 days. Can we do it? To answer this question, we need to find out all the user stories at the beginning of the project, and then evaluate how long each development process takes. But how can we evaluate it?
For example, we have collected the following user stories:

Selling drinks: as mentioned above.
Cancel Purchase: After you make some money, you can cancel the purchase.
Enter the management password: the authorized person can enter the management password, add inventory, set the price, and take away the money.
Supplemental beverage: Authorized Persons can add inventory after entering the management password.
Take out the money in the cash box: After the authorized person enters the management password, the money in the cash box can be taken out.
Security alert: if something happens frequently, the system automatically opens a security alert.
Print monthly sales report: an authorized person can print a monthly sales report.

Then find out the simplest user story ("simple" here, which means the implementation cycle is the shortest ). We may not be very precise in determining which one is the simplest. Just pick out what you think is the simplest. For example, "enter a management password" is the simplest user story. Then we judge that this user story is regarded as a "story point )".

User stories
Selling drinks
Cancel purchase
Enter management password 1
Supplemental drinks
Get the money from the cash box
Security Alerts
Print monthly sales report

However, we generally do not list the list, but instead stick a pile of cards to the wall. Each card records a user story and then writes the story on the card:

Such a card is called"Story card)".

 

 

User stories are usually expressed in the following format:

English:

As a <role>, I want to <activity>, so that <business value>.

Chinese:

As a <role>, I want to <activities> to facilitate <business value>

Example:

As a "website administrator", I want to "count how many people visited my website every day" so that "my sponsors know what benefits my website will bring to them."

Note that user stories cannot be described in technical languages and must be described in a business language that users can understand.

3 C of Ron Jeffries

About the user story, Ron Jeffries uses three C to describe it:

Card)-User stories are generally written on small memo cards. The card may contain a brief description of the story, workload estimation, and so on.

Conversation )-The details behind the user story come from communication with customers or product owners.

Confirmation )-Confirm that the user story is completed correctly through the acceptance test.

 

From: http://www.cnblogs.com/henryhappier/archive/2011/02/23/1962617.html