用户故事规范(国外英文资料).docVIP

用户故事规范(国外英文资料) The rules of good user stories In the Sprint planning meeting, dividing the user stories is an important activity. When dividing a user story, be sure to follow the rules of user stories. The concept of user stories: A user story describes a function that is valuable to a software (or system) user or customer. User stories include three aspects: the written description (for planning and cheat), conversation (refinement story details), and test cases (validation) story. Written description - including the description of the story, for whom the service, the unique identification, the prompt information, is helpful for the iteration planning. Talk - engage in face-to-face communication with users, taking notes, models, and documentation. Test case - the standard for the acceptance test, which is how the user can confirm that the story is close to completion. A good user story contains three elements: role, activity, and business value. The role is the user of the function, the activity describes the function that needs to be done, the need for the business value description function and the value of the function. The format of the user story is: as a character , I want activity for business value . Note: the user stories cannot be described in technical language and are described in the business language that the user can accept. The difference between user stories and use cases: The user story is about the memos, not the documentation. The use case requires a detailed description of the period action steps, along with each exception path. A user story is a visible business value, not a functional description. The granularity of each user story is similar to that of the workload. User stories are fine-grained, testable, visible, and valuable. The features of good user stories: A good story has six characteristics: independence, negotiability, value to users or customers, predictability, short, and testing. Independence: avoid dependencies between sto