"User Stories and agile development" read Note 04

"User Stories and agile development" reading notes

Today I took two hours to read the 12th, 13, 14 and 15 chapters of user stories and agile development and wrote this reading note. The 12th chapter is titled "Story is not what". IEEE 830 is a guide to how to write software requirements specifications, and the most prominent feature is the use of the phrase "system should ...", but the author argues that all the requirements of writing systems in this way are actually an impossible task. Because users see the software being developed there is always an effective and important feedback loop. They will change their previous ideas, and the cost of each requirement is not visible, causing the analyst and the developer to have a big gap in the estimated time for a demand, so the author suggests that the user story is not IEEE830. User stories are not use cases either. Both aim at delivering business value, but the story is smaller in scope and the use case is permanent, and the story generally does not exceed their iteration. The user is not a scene, the scene contains more details, and their scope often contains multiple stories.

The 13th chapter "The advantage of User Stories", the author in this chapter briefly introduced the advantages of user stories, in general, is the following: User stories emphasize verbal communication; everyone can understand user stories; user stories are suitable for planning; User stories are suitable for iterative development; User Stories encourage deferred details User stories support resourceful development, user stories encourage participatory design, and user stories disseminate tacit knowledge.

The 14th chapter, "A list of undesirable indications of user stories", shows some of the bad signs of using user stories in this chapter. It is often necessary to adjust the estimate generally because the story is too small, if the story has dependencies, it will do iterative planning, there is also called "gold-plated", that is, developers do not need to implement the function, in the iteration to achieve the unplanned function, but also too much detail, premature consideration of user interface details, think too far, Stories are too frequent, customers struggle to prioritize stories, customers are reluctant to write user stories, and are reluctant to prioritize stories. for these undesirable signs, we must find and find the appropriate solutions in time.

The 15th chapter, "Scrum" and the user story, "scrum" is an iterative and incremental software process. There is a scrum brief every day during the software development process, asking members to answer three questions: What did you do yesterday? What are you going to do today? What's the problem? The author describes the use of user stories in sprint review sessions, and the use of user stories in the daily Scrum brief, which is helpful to us in the future use of stories in software development.

"User Stories and agile development" read Note 04