5. Agile development user Story Series: Classification of user stories

This is the fifth article in the agile development user story series. (Topic directory)

 

Introduction

In No. 1, No. 2, and No. 3, we once mentioned "as ...... Yes ...... So that ......" To better reflect customer value.

Let's try to describe these two stories:

1. If you place the "Save button" on the top of the page rather than the bottom of the page, you do not need to scroll the screen to save the modification of some controls on the screen.

2. All custom fields should be changed to nvarchar of 4000 length.

The first one can barely write: "as a user, you can easily click the Save button at the top to save some widgets when they are modified without scrolling ", however, the granularity of this story is too small, and it may take only one hour for development. In the eyes of the customer, it should not be like "as a user, you can add, delete, modify, and query the story so that ......" Put together.

In the second story, we cannot find the "user" location because it is an improvement we have to make, so customers can be unaware of it.

What should we do with such stories?

Category

There are various classification methods to reorganize user stories. below is my own classification, not a mature method.

Therefore, when using these methods, you mustUnderstand the intent rather than the method, so that you can modify it flexibly when you have other intentions..

When I developed a small software, I found that listing all the user stories together was obviously extremely messy, so I made a large tree structure to display them.

The results show that despite the high screen utilization rate, it is difficult to see the main features of the product at a glance, because the stories of both big and small are crowded together, and some are the selling points of the product that customers should see, some of the refactoring tasks are only related to the development team, and some are between them. The product manager needs to know but does not need to tell the customer.

In addition, there are differences in the size of what you want to see for the customer. For example, in the example above, if you are in the "Product Version update announcement", you can write it. But for new customers, no, they can accept the product as it was.

So my general classification dimension is:X-axis is the degree of display to the outside world, and X-axis is the granularity.. To a certain extent, the granularity is "the degree to which it is necessary to present", that is, the product features can be displayed in a simple and traditional manner.

Granularity		Visible to customers		Visible to product manager	Visible to the development team
Product Features	Data level	Epic			Restructuring debt
	Operation Level	Function
Version release description	Enhancement level	Enhanced	External Defects	Internal Defects

Granularity dimension

A file is a set of data to be operated. For example, a system with user management must have "users, roles, permissions ......" The data to be operated. Files are the data that users of the system can understand.

An operation refers to operations on a group or multiple groups of data. operations on a group of data start with "create role" and "delete user ", operations on multiple groups of data, such as "assigning roles to users", feature that an operation is a business operation (that is, a "work" operation) of a system user. operations are a verb.

The so-called enhancement refers to the content used for attributions, inactive comments, and complements. For example, the case 1 in the introduction is for the convenience of users. It is neither the data to be managed by users nor the operations that users usually work on.

This dimension is easy to understand at the "customer visibility" level.

For example, to describe the features of a product, you only need to display the customer's visible epic and features.

For example, when describing the product version release description (upgrade announcement), you should display the changed epic, function, and enhancement. (Post-defect interview)

For more information about this dimension, see http://blog.csdn.net/cheny_com/article/details/6723715.

Degree of presentation

In addition to what customers can see, there are some things that need to be known by product managers and development teams themselves. The scope they know is forward, that is, what customers can see, what product managers can see, what product managers can see, And what development teams can see.

There are two types of defects that the customer has proposed and discovered. The former will be displayed to the customer (in the product upgrade announcement), and the latter will be available to the product manager.

Refactoring is caused by the convenience of development, maintainability, performance, and re-design of functional implementation methods. You do not need to disclose it to the customer and product manager.

Debt is what developers may leave behind as a "shortcut. This "possible problem" means that problems may occur after changes to the functions and structures in the future, rather than problems with the current operations (which should be called defects ). Therefore, you do not need to make corrections now, but also need to leave a mark for future reference.

Actual usage

In actual projects, I found that such classification may vary depending on different projects. For example, we want to add three types of internal poems, internal functions, and Internal enhancements recently, because some functions are made for internal development convenience, and there are also differences in files, operations, and enhancements.

We also set different stories like "as ......, Yes ...... So that ......" But it is not very mature and will be shared with you later.

Therefore, the classification method is often changed in specific management, so the content of this article will change in the future. You should also rethink whether the previous classification is appropriate in each project.

 

 

Click to download the free agile development textbook: Martian agile development manual