Collect User stories

I. Differences between traditional and agile methods:

The feature of the traditional method is that it overemphasizes the correct acquisition and writing in the early stage of the project.All requirements;

Agile projects feature that there is no ideal way to get all user needs at a single stage.

Ii. How much user stories are sorted at the beginning of the project:

Four words, enough. You can write as many user stories as possible before the project starts, but it does not take months to write user stories before the project starts. On the contrary, it requires you to look forward to a future release time. The later the story is released, we don't need to write this story in detail. It can be expressed by a placeholder, for example: the customer said they wanted a report function. You do not need to describe this function in detail (for example, how to implement it ).

3. capture user stories:

Networks of different sizes are used to capture the needs of different sizes. For the first time, we can use a large mesh to capture the demand pool to obtain all the large demands, through these big demands, the software will feel like a whole, and then we will use a slightly smaller mesh network to get it again, so that we can get a medium size demand, at the beginning, there is no need to consider small demands. (Some requirements may be missed, but it does not take any time to catch them)

4. Importance of stories:

Some requirements may be missed during fishing, because this requirement is not very important to the software. Like fish, the story will grow and die. According to the feedback of each iteration, it will develop in an unpredictable direction, and some demands may become unimportant or even useless. Previously missed (not considered important) demands may become more and more important.

5. Methods to capture user accidents:

1) User interview: this may be what every team wants to talk to customers face to face. The key to successful interviews is to select the correct respondents, access real users as much as possible, and access users with different roles. When talking to a user, do not think that the user is right. Maybe your opinion and practice are better than what he thinks, so that he is more satisfied. The way of talking is also very important. When I access, I try to use open-ended questions as much as possible, rather than closed-ended questions. It is best to ask questions that are irrelevant to the background. If you start to ask a question, you may miss many stories. Do not allow respondents to answer your questions only if they are "yes" or "no", "right" or "wrong", "OK" or "no ".

2) Questionnaire Survey: If you need to wait for a large number of usersAnswers to some specific questionsIs very useful. However, it limits users' ideas. It is difficult to summarize multiple answers if you can give them a free answer. It cannot be the main method of fishing stories.

3) observation: when others use their own software, they will get a lot of ideas to improve user experience or productivity. Unfortunately, there are few such opportunities. Therefore, do not miss out on any opportunities for users to use your software.

4) Story Writing Workshop: a meeting attended by developers, users, product customers, and others who are helpful in writing stories. Participants during workAs many as possibleTo write a story (whether good or bad), not to rank the priority, and finally let the customer rank the priority. Story Writing workshops are the most effective way to quickly develop stories, at least before each plan is launched. Although this is good, there is no need to hold too many story writing workshops throughout the project. The discussion in the Story Writing Workshop is at a higher level. Our goal is to write more stories in a short time, rather than how to design and implement them.

5) Demonstration: similar to observation, when demonstrating the software you have made for others, you may feel uncomfortable with some of them, viewers can also give better suggestions on this function as soon as possible. Get user feedback immediately

V. Summary:

1) The idea of introducing and capturing requirements is wrong. It has two problematic assumptions: the user knows all the requirements, and once the requirements are captured, they will be locked and will not change.

2) the trawl fishing metaphor is useful: it shows that the demand has different sizes, and the demand will change over time. It requires some skills to discover the demand.

3) Even if agile processes support the emergence of demand in the future, you still need to look forward to the expected release and begin to write a story that is easy to discover.

4) we can discover user stories through user interviews, user observation, questionnaire surveys, user demonstrations, and stories compiling workshops.

5) using multiple methods is more effective than over-using one method.

6) it is easier to obtain useful answers through open-ended questions that are irrelevant to the background. For example, "tell me how you want to search for a job ?" It is better than "do you want to search for a job by position ?".

Vi. Responsibilities of developers:

1) understands and uses various techniques to capture user stories.

2) ask questions about how to use the open architecture and the background.

VII. Customer's responsibilities:

1) understands and uses various techniques to capture user stories.

2) write more user stories as soon as possible.

3) as the main representative of software users, they are responsible for communicating with them.

4) ask questions about how to use open architecture and irrelevant background.

5) if a low-carbon elder brother needs to write stories, he is responsible for arranging and holding one or more story writing workshops.

6) ensures that all user roles are taken into account during fishing stories.