[Post] agile development, use case or user story -- I feel like the difference between "User Requirements" and "requirement specification"

[Post] agile development, use case or user story

 

In Agile development, use case or user story Murali Krishna tells us that failing to fully understand the nature of user stories is often a major problem of failing to effectively transform to agile development. The most important feature of a user story is that each user story is an independent requirement (feature) unit. To achieve "independent allocation", we need to use the system to express user stories from "users. This allows you to implement a functional unit that enables user communication, end-to-end (from the user interface to the backend. Murali wants to be the same as many people in Agile communities-user stories are the best choice and reference an article by Mike Cohn titled advantages of user stories for requirements. It is pointed out that: 1. every user story includes three aspects: 2. write down the story description for planning and prompting 3. the story dialog is used to record the story details and test the details. It seems that it is better to use a user story to determine whether the story is completed or not. But is that true? Alistair Cockburn, another famous in the agile community, still uses use cases and points out the problems encountered from his past experiences using user stories: 1. user stories and projects on the backlog cannot provide the context of the content required by the designer's work-when and when the user is doing this, and the high-level goal at this moment. 2. user stories and projects on the backlog cannot provide the "integrity" required by the project team. I found that the story points estimated by the development team keep increasing as the work begins, it is like endless. Developers and project sponsors are equally frustrated. How big is the project? 3. integrity is related to the fact that user stories and projects on the backlog cannot provide an appropriate mechanism to take into account the difficulty of future work (in principle they can, but actually they cannot) -- I keep receiving such a complaint: "We asked the customer (Product Manager) a question. It took him or her two weeks to reply to us. Are we looking for the wrong person ?」 No, they didn't find the wrong person. They had a problem in the process-some questions need to be studied for a long time, because different departments and user groups need to find out what is correct and balance the answers needed by all parties. The analyst can find out which one is easier and more difficult by looking at the extended series in the use case, and then conduct relevant research. User stories and backlog projects fail to reach the granularity suitable for consideration in a timely manner-the extended situation is usually observed in the sprint, which is too late. After Alistair says "why not use user stories", he further discusses "Why use cases 」. 1. The target name list briefly summarizes the contributions of the system to businesses and users and provides them to administrators. This also provides a project planning framework that can be used to set up initial priorities, estimates, Team allocations, and time options. This is also the first part of "integrity. 2. The main success scenarios of each use case can provide protocols for participants about the basic functions of the system. Sometimes, more importantly, they can tell people what they cannot do. Providing context for each requirement is difficult for other tools. 3. The expansion conditions for each use case can provide a framework for the demand analyst to find out the cumbersome nuances that may take up 80% of the development time cost. It provides a mechanism to consider the future, so that customers, product owners, and business analysts can perceive issues that may take time to study. These issues should be prioritized so that the materials are prepared when the development team starts to work. This case extended the situation analysis is the second part of "integrity. 4. the use case extension scenario provides some details that are often hard to handle, as programmers often ask: "How do you want me to handle this situation ?」 (Normally, the reply is: "I don't know. I never thought this would happen .」) In other words, this is a framework for thinking and recording documents ...... So ...... Otherwise, it helps Programmers think about different problems. This is done at the research stage, not at the beginning of programming. 5. The entire set of Use Cases series reflect that the researchers have carefully considered the needs of different users, the purpose of different users in this system, and some business differences. This is the final part of "integrity. (Indeed, I discussed 240 cases in detail with the customer. At the end, I asked her, "Is this all ?」 She confirmed. We built the system, paid for the operation, and received the cost, which is still in use ten years later .) As many people have expected, this is not a clear black/white issue. How should we do well? Is what we are doing useful? Is there only one correct method? Are there two different correct methods? Or depends on the actual situation? Will it be better to use cases in some cases, but better to use user stories in some cases? In fact, there are not many differences. For example, a use case contains multiple user stories. This use case seems to be a user story both inside and outside the user plot.) Note: user stories are good or use cases are good. In fact, unlike most of the tools that I mentioned earlier, iconix, FDD, and Openup depend on or support use cases, however, it is extremely important to understand the two. Only when you know the difference can you make the appropriate decision. Scott Ambler once pointed out the differences between the two:

Tools	Common applications	When to save
Use Cases	1. Overview of Main Application Requirements 2. Analyze existing system usage requirements	Usage requirements Overview
User stories	1. Explore user needs 2. Prompt for dialog with project participants	After the function is implemented, discard it.

The usage and purpose of the two are obviously different. Even if necessary, the two can be used and exist together. There is no such thing as a better problem, and we should not rely solely on some reports to say that it is better than that, so we can follow it. The important thing is how to better suit the current situation, including project needs and team capabilities. In the long run, it is to make the team more agile. In my own practice: User stories are used in Po-to-Customer communication and Po and team-to-Sprint planning. Use Cases are used by the team in the explicit requirement or requirement analysis phase and PO confirmation. However, the use case needs to be cropped from the article: mongoamr elssamadisy translator Mai Tianzhi Andy yuan, Yuan bin, Senior agile consultant of xunsiwell MSN: agiledo@hotmail.comMobile: 13501397696 xunsiwell-domestic professional Agile Project Management and agile development process training, practice base, welcome to visit http://www.agiledo.cn