Project Management (12)-The writing Story of Agile Development

In this chapter we will focus on the story writing, in order to better construct the story, we focus on six features, a good story should have the following 6 aspects of the characteristics

6 Characteristics of a story

1, The Independent

Avoid the interdependence between stories, when prioritizing stories, or when using stories to plan, the interdependence between stories can lead to problems

2, can be discussed

The story is to be discussed, they are not signed good contract or the need to achieve in the software needs, Agile story is a short description of the function, the details will be in the customer team and development team discussions, the story is to remind the customer team and the development team to carry out the dialogue on demand, it is not the specific needs themselves, Thus it does not need to contain specific details. These details can be discussed at a later stage, such as the scrum planning meeting

3, to the user or customer is valuable

"Every story has to be valuable to the user", which is not true, and many projects contain a story that doesn't make sense to the user, remembering the difference between the user (who actually uses the software) and the customer (the buyer of the software).

For example, many companies now do telecommunications projects: the customer is a telecommunications provider, but the user is indeed the masses of people, like "5 servers cluster" such stories, no meaning to users, the masses only care about services, but for customers, this story is very meaningful.

The reason why the above story is to say, the story must be to the user or customer value, do not appear only to the developer of the story of value

For example:

1. All database connections are taken from the connection pool

2, configure the program's log4j log output, and configure the log level.

As these stories focus on the technical and implementation details, the ideas behind these stories are good, but the story is not written to reflect the value to the customer or user.

The above story can be replaced by the following form:

1, this software, up to 50 users can use 5 user's database license

2, all errors should be presented to the user in a unified manner and record

4. An estimate

Stories are estimates of the amount of work that can be estimated in size, which translates the story into code.

The following 3 aspects may cause the story to not be properly estimated

1, developers lack of domain knowledge

2. Lack of technical knowledge of developers

3, the story is too big

5, the Small

The size of the story is critical, and the story is too big or too small to help customize the plan. If the story is too big, such as "a user can plan a vacation", planning a vacation contains a series of tasks, women this big story into an "epic story", with this story we want to split into smaller stories,

The size of the right story ultimately depends on the team, its capacity, and the technology used

The story is too big to divide the story

The story is too small to merge the story

6, can be tested

The story must be testable and successfully tested to prove that the developer correctly implements the story.

The non-testable story takes place in the absence of functional requirements, which are related to the software but have no direct relationship

1, the user must feel that the software is very useful

2, users do not need to spend a long time waiting for the window to appear

This 2 story is not testable, whenever possible, it is necessary to test automation, the correct 99% of the story is testable. When product incremental development, a lot of things change quickly, the code that can work yesterday, today will have problems, this time need to pass automated testing to identify these problems as early as possible.

A summary of the characteristics of a story

In the case of the project, the story is independent, sometimes it is difficult to do this, but we have to do our best to achieve. The order of delivery between stories should be irrelevant, and you can take a story to achieve it.

Story details are discussed by users and developers

The story should be clearly reflected in the value of the user's live customer, the best good thing to let customers write stories

The story can be annotated with some details, but too much detail can make the story difficult to understand, or it may give a story that is detailed and does not need to communicate with the customer.

The best way to annotate a story rockery is to write a test case

If the format is too large, meeting stories and complex stories can be divided into several small stories

If the story is too small, several small stories can be combined into one big story

The story is supposed to be testable.

Developer Responsibilities

Be responsible for helping customers write stories that remind you to talk to your customers, rather than documenting detailed requirements definitions, stories that are valuable to users or customers, independent, testable, and well-sized

If asked about the technical or infrastructure information used to implement the story, it should be described using terms that are valuable to the user or customer.

Customer Team Responsibilities

Be responsible for writing stories that remind you to talk to developers rather than documenting detailed requirements definitions that are valuable to the user or yourself, who are independent, testable, and appropriate in size

Project Management (12)-The writing Story of Agile Development