Learn agile development step by step: 3. How to Write user stories

This article is based on the book "user stories and agile methods" after attending the agile1001 Open Class in January this year.

1. What is a user story?

User stories are valuable functions for users. Good user stories should include three elements: Role, function, and commercial value.

The common format of user stories is: as a <role>, I want to <function> to facilitate <business value>. A good user story includes three elements:

1. Role: Who wants to use this function. 2. function: What kind of function is required. 3. Value: Why does this function need and what value does it bring. User stories are usually expressed in the following format: As a <role>, I want to <activity>, so that <business value>. chinese: As a <role>, I want to <function> to facilitate <business value>: "as a registered user of a recruitment website, I want to view the recruitment information released in the last three days so that I can see the latest recruitment information ". Since the description of a user story is written on paper cards in a traditional way, Ron Jeffries (2001) calls 3C cards and conversation for these three aspects) and confirmation ). Cards: User stories are generally short descriptions and workload estimates on small cards. Conversation: the details behind the user story come from communication with customers or product owners. Confirmation: the acceptance test is used to confirm that the user story is completed correctly.  2. How to Write user stories should clearly reflect the value to users or customers. The best practice is to let the customer team write stories. The customer team should include persons who can determine the software end user needs, possibly testers, product managers, real users and Interaction designers. Because they are at the best position to describe the requirements, and then they need to design the story details and determine the story priority together with the developers. To construct a user story, we focus on six features. A good story should have the following features :? Independent(Independent): we should avoid the dependency between stories as much as possible. When prioritizing stories or using stories for planning, inter-story dependencies can make workload estimation more difficult. We can usually reduce dependencies in two ways: 1. Merge interdependent stories into a large, independent story; 2. Separate stories in a different way .? Discussed(Negotiable): The story card is a brief description of the feature, details will be generated in discussions between the customer team and the development team. The role of the story card is to remind developers and customers about their needs. It is not a specific requirement. A user story card has too many details, which actually limits communication with users .? Valuable to users or customers(Valuable): User stories should clearly reflect the value to users or customers. The best practice is to let customers write stories. Once a customer realizes that this is a user story and is not a contract and can negotiate, they will be very happy to write the story .? Predictable(Estimable): the development team needs to estimate a user story to determine priority, workload, and plan. However, it is difficult for developers to estimate the cause of the story: 1. developers lack domain knowledge; 2. developers lack technical knowledge; 3. The story is too big .? Small(Small): A good story should be as small as possible in terms of workload. It is best not to have more than 10 ideal people/day workload, at least to ensure that it can be completed in an iteration or sprint. The larger the user story is, the higher the risk of planning and workload estimation .? Testable(Testable): The story must be testable. The successful test proves that the developer has correctly implemented the story. If a user story cannot be tested, you cannot know when it will be completed. An example of a non-testable user story: Users must feel that the software is useful. Iii. How to split stories

When the story is very big, it will be difficult to estimate it. If the story is expected to be executed after N iterations, the story is normal. However, if it is estimated that it will be carried out in the next iteration, we may split the big story. A lot of stories can basically be split, as long as you determine that each story can deliver business value. Note that you should not split the story into tasks here. Stories are deliverables and are of interest to the product owner. tasks are non-deliverable and the product owner does not care about them, tasks are split at the sprint scheduled meeting.

Split user stories:

1. Split large user stories based on the data boundaries supported by user stories (such as importing GBq files and Excel files ).

2. Remove the handling of exceptions or error conditions (equivalent to the basic path and extended path of the user) from the main user story, thus reducing a large user story much.

3. Split large user stories into independent creation, reading, updating, and deletion operations based on Operation boundaries (for example, two-step budget import, you can also create a story to describe the wizard and rules when adding a new one ).

4. consider removing cross-cutting considerations (such as security processing, logging, and error handling) and create two versions for the user story: one with support for cross-cutting considerations, and the other with no such support.

5. separate functional and non-functional requirements into different user stories to separate large user stories (performance ).

When splitting a story, we sometimes need to consider the scenario of combining stories. For example, when we include bugs in the product backlog, we can combine multiple similar bugs into one story.

4. How to assess the priority

The simplest way is to ask the customer what features they want most in the next iteration. We can consider the following four factors:

1. Obtain the economic value of these functions. The higher the value, the higher the priority.

2. Impact of development costs. For example, it may take only two weeks to use the new technology after two months, but now it takes two months to use the new technology. In this case, you can lower the priority.

3. The importance of acquiring new knowledge. During development, some new project and product knowledge will be continuously generated. Early understanding and development of these new knowledge can reduce uncertainty, so this type of function has a higher priority.

4. There will be dependencies between stories. In this case, the priority of Dependencies will be higher and must be completed first.

5. The risk of developing these functions is reduced. In the development process, there will be progress risks, cost risks, technical risks, etc. The higher the risk, the greater the value, we need to first deal with it, the higher the risk, the lower the value should be avoided as much as possible, you can view the relationship between risks and values when determining the priority of a function.

5. How to perform initial evaluation

After initial estimation of each story, you can know the project scale. This type of initial evaluation is generally carried out using story points, which can be carried out through playing cards, playing cards are generally 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 ,? And coffee. First, the product owner will explain the product backlog, and then the scrum master will be responsible for coordinating the initial evaluation. In agile estimation, we do not need to estimate absolute time, but try to ensure that the relative estimation between stories is accurate. Because the estimation is relative, we need to first create a benchmark. We can first find a benchmark that is neither the smallest nor the largest, first, we can find a story that everyone thinks is suitable for the allocation of 2 points. When looking for a story at, it is very likely that the opinions of the people are inconsistent. In this case, you need to explain your opinions separately and try again. With a 2-point benchmark, you can evaluate each story, and subsequent stories can be estimated based on previous stories. During the estimation process, there may be inconsistencies in the understanding of the story. In this case, you need to return and modify the story to ensure that everyone understands the same story.

 

5. Excellent user stories

Guidelines for excellent user stories:

1. Try to make the story size feel free to have a cup of coffee break after use;

2. Do not expose the story to the user interface too early;

3. When writing a story, you must include the user role;

4. Write a story in the active voice;

5. Write a story for a single user;

6. Ask the customer to write stories, rather than developers;

7. The user stories should be brief. They only remind developers to talk to customers;

8. Do not add a number to the story card.

Summary of this Chapter

1. User stories are functions that describe valuable to users. User stories should include three elements: Role, function, and commercial value.

2. Excellent stories should have six characteristics: Independent, discussed, valuable, predictable, small, and testable

3. When the story is very large, it will be difficult for us to estimate it, and it is necessary to split the story.

4. The simplest way to evaluate the story priority is to ask the customer what features they want most in the next iteration.

5. The story evaluation generally uses the story points for such initial evaluation, which can be carried out through playing cards.

Learn agile development step by step: 3. How to Write user stories