This is the eighth article in the agile development user story series. (Topic directory) The content of this article comes from the experiences and achievements summarized by the Martian team after compiling the stories of 300 users in the Martian product, developers who are devoted to agile development and are confused about user stories are welcome to participate in the discussion. This article is especially suitable for students who participate in the MPD session "granularity, classification and organizational structure of user stories" and those who participate in the training of agile development products for Martians. In the user story, the most famous is the three-stage Syntax: "as ...... (Role), yes ...... (Function) ...... (Customer value )." However, this syntax is convenient to describe users' business operations. However, if it is used to describe non-functional requirements (including refactoring and defects), or to describe the enhancement of functions, it is a little effort. Let's analyze the user story syntax and try to write the syntax for other types of stories. Analysis
Why has the syntax of traditional user stories been successfully circulated for 10 years without changes?
"Because they were invented by masters ."
Wrong. Because they invented this syntax, they became masters. This is a result-and-effect inversion.
The real reason is that this syntax shows the three most important elements of a requirement: Role, function, and customer value.
1. helps developers understand the scenario.
Ordinary users/administrators, deposit customers/Bank staff ,...... These differences make it easier for developers to understand the product usage, style, operator proficiency, and Operation habits.
2. It is helpful to find a specific user for verification.
Whether it is a potential user survey of the product or a requirement verified with the customer in the project, if there is a "role" field, the communication work can be carried out with appropriate roles, the completed products will naturally satisfy the personnel of these roles.
The function is the best to understand, that is, the name of the function originally written by the programmer, or the title.
However, to put it in this syntax, you still need to use your brains.
1. Subject-predicate Principle
For example: (in a User Management System) "show all users" is not a good function. Why? Set it to the user story Syntax:
As a system administrator, all users can be displayed .......
Is it awkward? Yes, you should use "view all users" to make it better.
As a system administrator, you can view all users ....... Much better.
However, do the names of all user stories have the same functions as those in the syntax? You cannot write a name named "show all users", but the content is "as ......, You can view all users ....... "Story?
Yes, but don't write it like this, because it violates the dry principle.
The dry principle is the don't repeat yourself principle. Do not do one thing twice, especially something that is similar and confusing.
Therefore, a good function is a predicate with the user as the subject.
2. Expression principles
If a user is created, deleted, edited, or viewed consecutively, can the User write "new" "delete" only?
This is an issue that we actually discussed during a training session.
In theory, this scenario can be used (with some minor problems), but there may be major problems at other times.
Small problem: "Viewing" is usually divided into "viewing all user indexes" and "viewing details of a single user.
Big problem: If a story needs to exist independently in a story board, burned out chart, my personal center, or other places, the object of the action is lost, there will be multiple "new" "delete" stories, which are easy to confuse. It is better to "create a user" and "delete a user.
The Martian tried various solutions during the development process. The final best conclusion is:
Story Title = function; Role-function is the subject-predicate relationship; function itself is a verb-bin phrase.
User value seems simple and hard to write.
See: as an administrator, you can view all users to understand which users are in the system.
It looks pretty good, right? However, if the system is a csdn blog with 6 million registered users, why should the Administrator check all users? How can he view all users? What if this system is QQ?
Therefore, an administrator does not view all users for no reason. However, you cannot view the user (otherwise, you cannot view details, delete, appeal, retrieve password, ban ......), However, finding a reasonable reason for the administrator and viewing a user in a reasonable way is the correct story.
Case study: new users in Mars
As an administrator, you can create a new user in the system. "
It seems okay, but it is a bit nonsense. What should I do?
After writing 300 user stories in person, we can try this:
1. Try to find the actual purpose of the function, and then write the user value different from the function.
As an administrator, you can create new users to add specific users to the Martian system. "
No matter what the soup or medicine is, read it easily.
But if you think it is not good enough, try 2.
2. Try to add some adjectives, adverbs, and strong words to describe the core value of stubborn and undescriptive user stories.
What is core value? Some operations require "convenience" and "quick", while others require "security" and "consistency", which is the core value.
As an administrator, you can create new users to quickly add specific users to the Martian system. "
Well, it seems OK. But ...... If an administrator needs to create, save, create, and save users one by one in the pop-up window ...... This function may be quick, but it is not quick for the end service to add 1000 users.
Therefore, see 3.
3. If you feel that a user story cannot satisfy the core value, try to improve the story or change a new story.
As an administrator, you can create users in batches to quickly import existing user data. "
Batch creation is much faster than creation. One user in each line is separated by commas ...... But what if an error occurs?
The input data does not meet the requirements. Check whether the format is correct. "
But what if there are 1000 rows? Amount ...... See 4.
4. Verify that the improved user story can achieve the core value.
To be quick, you should locate the problem quickly.
In this case, all successfully recognized users are saved for storage, and all unsuccessful rows are left on the screen (up to a few rows). After modification, they are recognized again until all rows are successfully saved; after confirmation, start batch creation.
This process does not need to be written in the story syntax, because there is no place to put it. But it should be written in the requirement details/test cases.
Well, this is the "batch create users" experience of the Martian products.
Syntax of different types of stories
Let's try to compile a set of syntaxes for other types of stories (non-functional requirements. First, two problems are solved:
1. What are the most important elements of this story?
2. How can we highlight these elements in writing?
After writing more than 300 user stories, the Martian team found a set of their own syntax and preset it in the Martian product. (Please follow this blog in middle August, learn about the online experience system ).
Before looking at the specific examples, let's write a summary to help you understand why we have identified these elements.
1. Most roles are required
Enhancement, refactoring, bug ...... They all have their beneficiaries or victims. If there is no role field, it is difficult to stand on the real position to guess their real needs, and it is difficult to find someone to verify and ask for priority.
2. Customer Value (or potential loss) is required in most cases
If the customer's value (or potential loss) cannot be identified, it cannot be determined whether the business effect is achieved after enhancement or reconstruction, or whether the potential loss is avoided after bug correction.
3. The locations of the original "functions" are different.
Several instances of Mars
Readers may not be clear about the background of these stories, but pay attention to the role of syntax formats.
Enhanced: highlight the current/previous/next sequence table (add an operation )-
A product manager,
View the External table
To highlight the tables of the current and previous iterations,
Think about the demand planning for this iteration.
In this instance, "After implementation, as ...... (Role ...... (Original function ,...... (Beyond the function), so that ...... (Beyond the value )." This syntax highlights the functional differences before and after implementation. (Only for Enhanced Function descriptions)
In the enhancement type, an enhanced function is generally implied, but the description content is beyond the function and beyond the value. Refactoring: refactoring the interface and viewmodel-
In the middle of the tree, both sides of the tree occupy more space for iterative presentation, and the height of the tree is too large to be fully viewed;
With the story tree as the main body and the current iteration story on the left side, viewing and operations are faster.
In this instance, "Before refactoring ,......; After reconstruction ,......" The syntax compares the differences before and after reconstruction. This difference must be described for users so that product managers can correctly understand and sort the differences.
Defect: when adding a story, the product button is not refreshed-
A product manager,
Add or remove stories
, The person-day data on the top product button is not refreshed,
Incorrect determination of the total amount and proportion of each product during planning.
In this instance ...... (Role ...... (Function ,...... (Symptom), resulting in ...... (Potential loss) "syntax expresses when, what kind of phenomenon will occur, and what kind of business problems. When some defects occur, the "Symptom" is not obvious (for example, data is not refreshed). Therefore, you must describe the resulting business problems in order to understand the essence of the problem.
Debt: hard-coded product ID-
The product ID in the link is hard-coded (direct access to the Martian ),
Deploy to the actual environment
In this instance ...... (Current temporary implementation method), in ...... In the future ...... (Possible phenomenon), resulting in ...... (Potential loss )." The syntax expresses the current technical reasons, when, and what problems will occur, and what potential losses will be caused.