Summary of user stories and agile methods

1. Write a story

This chapter only lists the characteristics of good stories. Invest: Independent, negotiable, valuable to users, evaluable by developers, small, and testable.

2. User Role Modeling

This chapter only lists how to obtain a user role, but does not provide a good basis for the Division. The specific method is a refined process.

• Brainstorm to find all possible roles
• Sort and check the relevance
• Merge and remove related roles
• Abstract user roles.

In addition, this chapter provides two categories of virtual roles and extreme persons to ensure our consideration is complete.

3. Collect stories

This chapter points out the similarities between collection requirements and fishing, points out that demand collection is a process from rough to refined, first big, then small, and gradually refined, and requires certain skills.

Agile user stories respect the details of latency and refine the stories to be made, while future stories can be relatively large. They can be considered only when the time is right.

The author lists some methods for searching stories: user interviews. Observation, questionnaire, and story writing studio.

In user interviews, you must obtain more objective information from users through open questions that are irrelevant to the background.

In the story writing studio, a prototype is first created by a high-level component of the system. The prototype is used for each role to discover the user story. When using the prototype, it is best to use the depth-first method to discover an Online Story and switch other functional lines. To help us discover stories, we can be inspired by answering the following questions.

• What is next most likely for the user?
• What errors will the user make here?
• What are users' confusions here?
• What additional information does the user need?

At the same time, the author suggests that the number of stories is more important than the quality at this stage.

4. Cooperation with user agents

This chapter lists some groups that may act as user proxies and provides questions about the corresponding groups acting as user proxies. It points out that if they cannot be integrated with real users, it is best to cooperate with multiple user agents to achieve software success. And release the software as quickly as possible for users to use. Once the software is released, the feedback from first-line users can be obtained directly.

• User Manager: The User Manager may not really use the software, or pay more attention to the management functions of the software. However, the User Manager has a certain say in the software application results, so it is necessary to have a good relationship with the manager and contact the real user.
• Development Manager: The development manager does not really use the software. They are more concerned about the technical advancement. Unless the Development Manager and the user's goal are the same, the Development Manager uses the user agent as one of the most dangerous options.
• Salesperson: The salesperson pays more attention to the number of features, not the quality, and pays too much attention to the loss of orders, which may lead to the loss of the long-term strategy of the technical line.
• Field experts: field experts are very important in field software development, but they may use the software from the perspective of experts, which may be different from the needs of ordinary users.
• Marketing personnel: similar to sales personnel
• Customers: users who decide whether or not they can use the software may have different purposes than users. They must be used as agents with caution.
• Trainer and technical support: using them may ultimately turn the system into training software or technical support software.
• Business analysts and system analysts: One of the good user agents, the problem is that they may analyze user problems too long and think too much, rather than investigating.

5 Acceptance Test

The author suggests that the customer write an acceptance test to determine whether the story is complete. These tests need to be determined before the developer writes the code, which allows the developer to write a more complete program during development, acceptance testing is part of development. Test Cases are used to explain the intent of the story to the development team. Developers still need to write unit tests to discover problems beyond acceptance testing.

The author suggests using fitness for acceptance testing.

6. How to compile excellent user stories

This chapter describes the methodology in section 1st and describes how to write a story that conforms to the Invest features. Many of these rules are consistent with those used to write valid cases.

• The author suggests cutting the cake by vertical splitting from the target story development. Each story can run through all layers of the system architecture.
• The story is closed independently, and each story completes a complete function for the user, making the user feel meaningful.
• The story contains the user role. You can use the template: I as (role), want (function), for this (business value)
• Although we can write stories for a type of users, some problems will become clearer from the perspective of a single user.
• Write a story with the user as the subject.
• Write cards for constraints. For non-functional requirements, rules that must be followed by the system can be written as a constraint card.
• Do not involve user interfaces as early as in the story
• Although the story is a good method for analyzing requirements in agile mode, other tasks can be used to describe the details of requirements, such as interface diagrams and interface documents. At the same time, the author emphasizes that the story is only a clue for communication between teams. The story cannot contain all details, but it can record relevant clues for consideration during communication, including acceptance testing.

7. estimate user stories

Agile uses story points to estimate user stories. Different teams can define different points of meaning. One point can be an ideal person-day, or an evaluation of the difficulty of the story can be completed, you only need to evaluate team members in a consistent way.

In an agile team, the story is evaluated by the team rather than by the individual, which requires that the team members have little skill difference for the project.

The estimation method is to let a group of people sit together to evaluate how many points a story needs. For the details of the story, developers need to give the customer a detailed understanding to make a reasonable evaluation, if your assessment is inconsistent, you need to communicate with each other to eliminate these inconsistencies.

Triangle measurement is required for a group of stories evaluated. You can classify stories by number of points, check whether a story with 2 points is twice the work of story 1, and so on.

The story points completed by the team in each iteration can be used as the development speed of the Team for reference in subsequent iterations. It should be noted that the rate point is the evaluated point, rather than the number of points that have been corrected later.

The author believes that the difference between 1 point and a large number of points is not an error. Team members do not need to discuss the difference between 1 point. Therefore, the author suggests a set of values for a story point: 1 2 3 5 8 13 20 40 80

8 release plan

A Roadmap is required for product development, which describes the list of key features of the product. From a roadmap, a release plan depends on two points: release time and story priority. With these two points, you can create a release plan based on the team's development speed.

Ideally, the release date is a time range, not a specific date. However, the priority of stories must be sorted by users according to the Moscow Rules, considering the risks of unfinished stories, the value of completed stories, and the impact of postponing a story.

There must be (must) There should be (shocould) There can be (cocould) There won't be (won't)

In addition, the stories should be sorted in a specific order, such as 1st and 2nd, rather than a very high, medium, and so on.

Even if the customer still needs the developer's time evaluation, the order can be effectively performed. Because the high cost may change the priority of the story, the corresponding high risk and architecture change level stories may affect the priority of the story. Of course, if you still choose high cost and high risk stories after the evaluation, the development team needs to meet the customer's needs.

One factor that needs to be considered during planning is the iteration length. Short iteration means more flexible changes and transparency, but it will cause some consumption. The opposite is true for long iterations. Regardless of the iteration length, it must be stable and cannot be changed at will.

There are three methods to obtain the initial rate of the team: Historical Values, guesses, and trial run.

9. Iteration plan

This chapter describes the composition of the iteration plan:

• Discussion story
• Break down tasks from stories
• Developers evaluate and undertake tasks
• Discuss all stories and evaluate the tasks to avoid making too optimistic commitments

10 measure and monitor the speed

Note that the number of points completed by each iteration cannot contain partially completed tasks.

• By recording the number of planned points and the number of actually completed points in multiple iterations, you can evaluate the change trend of the team's evaluation level and actual completion level.
• By recording the accumulated planning points and accumulated actual completion points in multiple iterations, You can assess whether the team can complete the release as planned.
• The iteration burnout diagram records the number of points not completed by the team after each iteration. When the task does not change much, it can also better predict whether the team's completion plan meets expectations.
• The overburn chart in the iteration shows the number of unfinished task points each day, which can help us predict the completion of an iteration. This requires team members to keep the whiteboard up-to-date at any time.

11. Other discussions in the story

The author first compares the story with the IEEE 830 software requirements specification, pointing out that 830 is too boring, difficult to understand, time-consuming, and difficult to manage changes.

Then, we compare the story with the use case, and point out the differences between the two in terms of survival, demand scope, integrity, and purpose.

In my experience, use cases are the results of waterfall needs and are relatively heavy. However, the use case analysis method is the same as the story analysis method, both of which take the user role as the starting point and take the user's valuable functions as the core. We can regard stories as a lightweight expression and application of use cases. In the software process, use cases can be used to organize stories. You can use case analysis to obtain multiple stories. Later, you can organize stories into use cases and generate documents to organize the relationships between stories.

12 advantages of user stories

The story is relatively small and emphasizes communication, so it is easy to understand. It is suitable for planning and evaluation. It encourages delays in details and supports random development to facilitate the dissemination of tacit knowledge. It is suitable for lightweight demand analysis of iterative development.

Of course, the story is not omnipotent. If a large project relies on communication between people, it is too complex, and the relationship between a large number of stories is difficult to organize and manage. Considering the traceability of requirements, some additional work is still required.

13 bad user story symptoms

• The story is too small
• Stories are mutually dependent
• Complete additional features or additional stories for the story
• Too many details
• Early consideration of the UI
• Think too far
• It is difficult for users to sort priorities: Generally, stories are too large and need to be split.
• Users do not want to write stories or arrange their priorities

14 scrum and stories

This chapter introduces some basic knowledge of scrum. We will not record it here. We will be able to understand the concept mentioned above and the correspondence between scrum in two days using scrum works.

As a whole, when you use scrum to run several iterations, you have mastered a lot of knowledge in this book. Reading this book is nothing more than organizing experiences into theories, this book is not very useful for mature scrum teams.