Principle of dividing user stories

In the agile development process, the user stories are used to describe the requirements into realistic and visible development tasks that can be iterated. Therefore, in the process of agile software development, the Division of user stories plays an important role in iteration and development.

A user story is a story described from the user's perspective based on its name. It is also a story that the user can understand, one of the most common mistakes that developers can make is to think about and divide stories from their own perspectives, which deviates from the original intention of user stories.

So what is a user story? First of all, the user story is refined and segmented based on requirements. Since it is refined, there must be a degree. How much granularity needs to be called a user story? This involves another key word that appears together with the user story, called the epic, which is generally a large-scale story. Epic has its own characteristics: it is composed of many large numbers of uncertain requirements (large fuzzy requirements), and epics itself has a lower priority, because you cannot directly complete iteration and development through it, you must first divide it into smaller real user-story. Apart from these two points, epics contains too many fuzzy requirements, therefore, many different features are often mixed, and a feature is a group of requirements that can be classified as one type. At the same time, there is an interactive value for a specific user.

There are three elements in user stories: Card, conversation, and confirmation.

Card story Description: by writing the story on the note card, in addition to the description of the story itself, it should also include the estimation of the time point of the story and the corresponding test behavior.

Conversation uses rich conversation content: the details of a user story are not defined by a developer or a po, but by communication between members of the project team and the po or customer.

The confirmation acceptance test can confirm that the story has been completed: After the user story is divided, it is implemented by the developer by encoding, but it cannot be completed by the developer's self-test and validation story, we need a series of acceptance tests to ensure that the story function is completed and the software runs as expected.

There is a general template used to describe the functions expected by users from the perspective of users:

As
Role, I wantDo something or a piece of functionality, So that
Achieve some business value or statement of intent.

AsRole, ThroughAn operationTo enableFulfill specific goals.

There are three different points in this template: User Role-who, action-what, and target-Why (reason ).

For example, fans of guomi can click the latest news bar on the official website to learn about the latest developments in real time.

 

The compilation of a good user-story should follow the Invest principle:

Independent: Independence

User stories should be independent (a bit similar to test case in UT) and should not depend on other user stories. If user stories are dependent, different priorities may exist between user stories. Only after the dependent user stories are completed can the dependent user stories be further developed. Generally, user stories can be combined or separated to reduce the mutual dependence between user stories.

Negotiable: negotiate

A user story is not a signed commercial contract contracts. It is developed by the customer or the Po in collaboration with the members of the development team, if too many rules and restrictions have been set up like a commercial contract at the beginning, it will not be able to communicate and negotiate better, nor will it be possible to divide user stories that satisfy the customer or allow the development to agree.

Valuable: Valuable

User stories must be valuable to end users. Therefore, you should write them from the user's perspective, describing one feature rather than one task.

Estimable: evaluable

The division of a user story requires sufficient domain knowledge, so that the story development cycle can be roughly understood when the I story is divided. In order to reduce the uncertainty of estimation, the story itself cannot be too large.

Small: short

The story should be as short as possible, not to mention the smaller the better. A short story can reduce the estimation error in the division process. The best story can be completed within an iteration cycle. If it is too large, you should consider splitting it into multiple user stories with smaller granularity.

Testable: testable

I personally think this is of the highest importance to user stories among all features. First, if a user story cannot be tested, it cannot be determined whether the story is complete. In addition, the corresponding acceptance test should also be automatically run, so that the test of the user story can be triggered at any time. Finally, the division of the story can be considered complete only after the Criteria for passing the acceptance test are defined.

There is a classic example of testable:

As a user, I want to be able to cancel a reservation so that I can get a refund for the trip not taken.

What and why are the elements mentioned above in this user story, So how should we perform the acceptance test? The simulation should be a real scenario, such as: whether the refund is full or partial refund; how long before the cancel is effective; how to confirm the refund with the user and so on.

Make an acceptance test case for a real scenario according to the previous assumptions and passGiven-when-thenTo set:

Given: "I" paid RMB to book a flight from Chengdu to Sanya three weeks later.

When: "I" canceled the trip one week before the flight departure.

Then: "I" should receive a half-price refund for the ticket reservation (RMB)

When the acceptance test conditions are set for user stories, they correspond to starting state --- "event ---" final state

For any user story, at least one defaule scenario must be set during the acceptance test.

 

I wrote a piece of code without thinking or thinking about it. Now I will do it first. I will change it later, Mark!