Series 6 of agile development user stories: Generation and organizational structure of user stories

This is the sixth article in the user story series. (Topic directory)

 

A requirement can basically be converted into a user story. After reading the fifth day of 1234, it seems that it is not difficult to fight tigers in the mountains.

The difficulty is to give a White Paper on the first day of a project or product: "Please list the stories ". At that time, it was not just an empty brain, but a thousand words.

When I did another thing the year before, I got a method by chance. I used it in an agile project last year to this year. It was really comfortable to list a lot of stories, the subsequent development process confirmed that they all met the characteristics of independent delivery, testability, and low coupling, which is a good story.

Introduction

This is actually mentioned many times in the previous blog.Cost Management of software projects. Note that projects are mentioned here, rather than product R & D. A project is a Class A and B project that pays and delivers the goods with one hand.

Previously mentioned:No matter how many methods sort priorities, as a product, the function that best reflects differentiated values should always be placed before everything else.

Here we will talk about:Regardless of the number of management methods, cost estimates should always be placed before everything.

Before this is not general, it is best to use a few sheets of A4 paper to deal with it, because when the boss just signs a contract, there is no need in his hand, no design, no story, just a few sheets of paper. Of course, another embarrassing thing is: even if there is a thick requirement document, there is still no way to know how long it will take to complete the project. It is really sad.

In fact, these two things refer to one thing:How to list requirements with a certain characterization significance in the Early Stage.

Early Generation of user stories

I have described this in detail in my previous blog. Here I will only talk about it from the perspective of generating and organizing user stories. For more information, see the link at the end of this article.

There are two types of things to be developed in our development work: Data and operations.

The so-called data, for example, is to write a CRM, which has three things: "user, role, permission", that is, the data to be managed. Here, the right to write down the user has"3 epic stories"To manage.

Operations mean adding, deleting, modifying, querying, and adding roles to users ...... These are called operations. Here, we have the right to write down the"5 user stories".

The following is a part of our actual project. The textbook is an epic, and the blue is a story with parentheses and a plus sign. The arrows are enhancements. Please refer to the previous story classification:

An epic is a noun, a core information to be managed, and can be understood by users;

The stories are all verbs, all of which are business operations performed by users using software products on weekdays;

The last tip is that each epic story has an average of about 7 stories, less than 4 to doubt whether it is an epic, and more than 10 to doubt whether it is necessary to split a new epic.

The last line is the nesma's 20 years of experience data, which is worth your reference, but it is not true. For example, the above example is divided into three epic versions: User/role/permission for 19 stories (an average of 6.3). You can try to split or merge them again, and the effect is definitely not as good as those three. It can only be said that they have never done anything for 20 years.

This method sounds very vague, but because I have offered several cost estimation training courses, I have received 3 training sessions, after just one day of training, 4 ~ The (maximum-minimum)/average error of the five groups is only plus or minus 12%, which is a major source of error. It is always noisy during a simulated Q & A session, and many teams did not pay attention to the answer! @ ￥ #... %! After checking the requirement, the error can be quickly reduced to about half. There is only one sheet of A4 paper in the classroom exercise, which vaguely implies more than 90 user stories. The exercise time is only one hour, and it is satisfactory to achieve such consistency.

Organizational structure of user stories on a large scale

At first, we had a meaningless hierarchical directory structure on top of the epic, but things were not complete, just like there was a galaxy outside the solar system, there was a supergalaxy outside the Milky Way, and there was a supergalaxy group outside the superstar system.

I thought there was no actual logical structure above the epic, but I found that the distance between the three stories "User Role Permissions" is far closer to other stories, there should also be something logically meaningful to describe; other epic stories also find this cohesion, but there is no rational way to define it.

I have created the "story group" concept for the moment to describe them, but I have not found a reasonable definition so that different people can divide the story group in a consistent manner.

 

The reason why we use the concept of Function Point Analysis to generate and organize user stories is that there is no standard granularity and organization method for user stories. For data and operations, then, nearly 40 years ago, we began to try standardized definition. There are currently five international standards, and China's national standards are coming soon. After receiving these standard training, there is only less than 10% of the data and operation count differences between different individuals. No definition of user stories can achieve such consistency.

The agile world has always been closedFor example, cmme is trying to embrace agility, but never heard of it.

We do not deny the experience and authority of front-line employees who create and use agile development in defining requirements, making plans, and tracking every day. However, they can grasp the organizational structure of user stories on a large scale, and in the early stages of judging the scope of the project, it is the weakness of this group.

The existing external methods need to be used for agile methods.

 

Why not use the UML method? I am not familiar with UML. UML is more suitable for organizing user stories on a large scale, but it is difficult to carry out in very early stages (an A4, containing 90 stories, which can be estimated in an hour ).

Of course, this will not erase the role of UML in analyzing user stories. In the future, I may ask another teacher to write an article "user stories and UML". I will forward it as one of them, for completeness.

 

Estimation of early functions 1: http://blog.csdn.net/cheny_com/article/details/6723708

Early function estimation 2: http://blog.csdn.net/cheny_com/article/details/6723715

 

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