Use sorting method to estimate user story

This article is a detailed explanation of sorting methods mentioned in the article "Weibo discussion on project estimation" published by Wang Xiaoming on infoq. I. Introduction

Estimation of software projects has always been a problem. Because software development activities cannot achieve the maturity of civil engineering, it is impossible to evaluate it through the budget quick query manual as it does for civil engineering. However, for an investment, it is always necessary to say how much it will invest, and the investment for software development should also be provided, which requires estimation.

This article mainly discusses user story Estimation in agile software development. There are many estimation methods, but they are generally divided into absolute estimation and relative estimation. In this article, "absolute estimation" refers to the estimation of absolute time (such as hours or days. The "relative estimation" means to compare the sizes of user stories. The estimated results do not have time units (the differences between them are not covered in this article ). There are also many different methods for relative estimation. In the relative estimation process, the following phenomena often occur, especially for those teams who use relative estimation for the first time:

• When determining the relative estimated benchmark unit "1", it is difficult for developers to find a suitable user story as a benchmark;
• Developers focus more on the number of points in a single user story, rather than the relative size compared with other user stories;
• The estimated total time is relatively long (usually the whole afternoon or even one day ).

The estimation method described in this article is only a summary of the experience that has been used by the author in the guidance work and has good results, but it does not ensure that it works in any situation.

Ii. Ranking estimation method 1. Purpose

There are usually a certain number of story cards for developing a release plan.

2. Used scenarios

The project is large (one to three months). A list of user stories has been obtained based on the user story splitting principle (invest principle), which has been discussed by the roles, consensus has been reached on the content of each user story. At the same time, the team can basically ensure that two or more developers can understand each card and have the ability to develop it.

3. basic rationale or assumptions

1. The objective scale of user stories will not vary depending on the specific development personnel (although the time spent may vary depending on the personnel ).
2. Developers are familiar with the work of each user story.
3. Because there are a certain number of user stories (from a statistical perspective), the objective scale will not deviate too much.
4. Developers are the bottleneck of the entire delivery process. Therefore, developers only estimate the development scale, excluding the Testing Scale of user stories.

4. estimation process

1. Write all the user stories to be estimated on the card and distribute them to the developers involved in the project (evenly allocated );
2. Let a developer take a card a and paste it to the wall (any card can be used );
3. Then let each developer stick the cards in their hands to the wall according to the following rules:
   1. Take a card B from your hand and compare it with the cards on the wall (at the beginning, there was only one card, that is, ).
   2. If the size of card B in your hand is the same as that of card a on the wall, paste it below card A, as shown in 1.

      Figure 1. The size of A and B is the same

   3. If Card B is larger than card a, paste it to the right of card A, as shown in figure 2.

      Figure 2 B greater than

   4. If Card B in your hand is smaller than card a, paste it to the left of card.
   5. Continue to take out a card C. If it is smaller than all the cards on the wall, put it on the left. If it is larger than the cards on the wall, put it on the right; it is about the same size as a card on the wall and is placed below it.
   6. If the size of C is between A and B, place it between A and B, as shown in 3.

      Figure 3 C: between A and B

   And so on. In this process, all developers can post cards at the same time, as long as they do not interfere with each other, to maintain independent judgment.

4. After all the cards are pasted, ask all the developers to check whether each card is properly positioned. 4.

   Figure 4 sorted card walls

5. If you have any objection to the position of a card, please discuss it out. This may be caused by inconsistent content and understanding. Therefore, we need to discuss it in depth until we agree on the column where it should be.
6. Use numbers, and 16 to place them in a column with contrast, as shown in Figure 5. Note: The size of some cards may also be discussed among team members, and positions may also be adjusted. In Figure 5, each story card listed in "2" should be about twice the size of the "1" column. Because it is an estimation, it does not need to be accurate, as long as it is equivalent, and so on.

   Figure 5 card walls with the size of each column set

7. For columns with no numerical identifiers on the column header (column "L", column "A", and column "K" in column 5 ), ask the developer to place it into adjacent columns Based on the closeness of the scale. 6.

   Figure 6 Estimated card walls

Finally, the number of user stories in each column is multiplied by the number in the column header. After the obtained number is added, the overall scale of the project is obtained.

Iii. Notes

1. Before estimation, make sure that the scale difference between all user stories is not too large. For example, it takes about one hour to complete a user story, and two weeks to complete another user story. In this case, the granularity of user stories is unreasonable. The s principle in the Invest principle must be merged or split.
2. If the number of cards in each column does not conform to the normal distribution, but the number of cards at both ends is large and the number of cards in the middle is small, it also indicates that there may be a problem with the user story granularity. You need to review it. In this case, it will bring difficulties to subsequent iteration plans.
3. If a column contains several associated stories of the same size (for example, supporting UnionPay cards, MasterCard, and Visa cards) and a card is completed, the other two will reduce the workload, you can put any one in the current column, and the other two can be considered in a relatively small column. However, the specific situation should be analyzed because the actual situation is complicated. However, such analysis and verification work is indispensable in the overall review process.
4. When discussing and moving a card, we should compare it more with other cards, rather than simply saying which column A card belongs. Because the numbers in the column header are relative values and there is no comparison between other cards, these numbers are meaningless.
5. During the discussion, some problems or information that have not been found will be captured. At this time, you must record them in time. For unclear problems, the business personnel should draw a conclusion on the spot.
6. When this method is used for the first time in a team that has not tried relative estimation, it is recommended that someone with some experience guide and properly verify the order.

4. A practical case

This method is quick. I have already done this several times. The teams involved are different, but the results are satisfactory. In the last practice, a total of more than 40 user stories took about 1.5 hours to complete the Scale Estimation and release plan. The following two photos are estimated at the time. Since the Team has been using the traditional waterfall development method and has tried agile development for the first time, in this estimation, the author does not require the team to use a digital sequence containing only, instead, we use a numerical sequence of 1, 2, 3, 5, 8, and 13. However, in the later stages of development, the team has the ability to split large user stories (8 and 13) into multiple user stories consisting of 1, 2, 3, and 5. In addition, it is worth noting that, as shown in figure 8, in this estimation, there is no user story in this column of "1. This is also a normal phenomenon. It is reflected from the aspect that not all estimates require the baseline "1 ".

Figure 7 the developer is posting a user story card to the wall and has not decided on the numbers in each column.

Figure 8 the developer is discussing which value column to place a user story without a value

V. Summary

For teams that have just been engaged in Agile Software Development, this method of Scale Estimation and planning is indeed not very easy to accept, especially in those teams that are used to using the WBS Decomposition Method for planning, how long does "1" mean, a day for senior developers, or a day for new users? Therefore, as mentioned above, such sorting has its prerequisites and assumptions. In addition, when splitting user stories, the team members should fully discuss and understand each user story. This is the prerequisite for the success of this method and, of course, the prerequisite for the success of agile software development methods.

It is worth noting that this method only estimates the development workload. The premise is that testing is not the bottleneck of the entire delivery process.

In addition, the Invest principles of user stories include: Independent, negotiable, valuable, and estimable ), small (small and similar size) and testability (testable ). The author believes that "S" has two meanings. First, "small": A good story should be as small as possible, at least ensure that it can be completed in an iteration. The larger the user story is, the higher the risk of planning and workload estimation. Second, "similar size": the scale of all user stories should not be too different. Do not create a user story that can be completed in half an hour in pursuit of "small, the result is dozens of times different between the largest and smallest user stories (don't laugh, we have seen this in reality ).

Originally published on infoq Chinese site, original link: http://www.infoq.com/cn/articles/ql-using-sort-method-to-estimate-user-story