Online seminar-Live text "Agile Development User story classification and organizational structure (two-1)" 2012-07-03

Phase One: Activity description, one, two, three, four, five

Phase Two: Activity description, one, BIS, three, four, five, six

Phase Three: Activity description, one, two, three, four, five

Review and the writing of common user stories (functions)

Chen-Entrepreneurship-Beijing (**9107533) 13:02:13
The lecture is divided into two phases because user stories have two important functions in the early and late stages.
In the early days, it is the data that describes, decomposes, and estimates requirements, and in the late stages, it directs development and responds to development. This is the advantage of the requirement entry.
In particular, we mention that in order to describe and estimate requirements more appropriately, the FPA method of functional point is obviously more advantageous, especially with tens of thousands of of statistical data, so the user story should be used to learn from it, rather than try to make a way out.
But today's content has nothing to do with the function point, it's about development.

Two period content:

1. Review of the first issue
2. What kind of user stories are there? which determines the product architecture. Which is the minutiae. Inconvenient to write "as a ... OK...... How to describe the story of ... ".
3. The User story organization structure: How "puts" the user story to be able to lose the overall situation. How to "see" The results of 10-year development.
4. User Story Follow-up development: The user story where to go later. Use cases, MVC these design implementation elements have to do with the user story of the requirements management elements of the corresponding relationship.

Chen-Entrepreneurship-Beijing (**9107533) 13:04:25
OK, now go to 2.

As mentioned before, if the user business Data + business operations as an epic story + user stories, you can well describe the structure of the product to the user, because it conforms to their business description method. But some stories, it is difficult to say that users can understand, such as:
1. Modify a defect; 2. Change the color of the interface; 3. Move the position of a button; 4. SQL Server is a component that is compatible with Oracle.
As a result, we found that in addition to the functionality that outlines the product's functional contours, there are some features that are "minutiae (some are not, behind)".
How should you describe these user stories? This I wrote more than 300 user stories, carefully weighed, summed up some new syntax.

First, let's review the syntax of the user story (this should be called "The syntax for user business operations").
As a ... (a role) that can be ... (of a function) so as to ... (To achieve the business value of a user)
Like what:
View Intent table: As a product manager, you can view the intent table to see which user stories are planned for the current and previous iterations.
Let's talk about this "intent table" first.
The intent table is a user data that we encountered when we developed the Martians
is actually the predecessor of Sprintbacklog.
Our tools are stored with product Backlog, which is all the items to be developed for the product, some of which will be selected for Sprint Backlog in the next iteration and done in the next iteration.
In the middle, there will be a transition state of things, that is, the product manager selected from the PB, but has not been estimated and discussed by the plan, this is the "intention table", discussed and estimated after the part of the commitment, it becomes a sprint backlog.

Chen-Entrepreneurship-Beijing (**9107533) 13:12:12
View Intent table: As a product manager, you can view the intent table to see which user stories are planned for the current and previous iterations.
That's the product manager, the story of preparing the intention table before the plan.
There are a number of similar business operations, such as:

Add Intent Story
– As a product manager, you can click on the story in the table of intent to quickly add it to the intent table.

Move the intent story
– as a product manager, you can click on a story already in the intent table to quickly move it out of the intent table.
.....
What is the benefit of these formulations? 1. a role; 2. Functional 3 is the key to having user value. Therefore, the things written by the user can understand, and developers will not deviate from the original intention of development, only immersed in the function (there are many functions, developed, but "can not use", is because the function is not equal to value)