Agile estimation: differences between story points and direct estimation days

Author: Chen Yong

Source: blog.csdn.net/cheny_com

 

The biggest advantage of direct estimation of days in agility is that it is intuitive. The disadvantage is that it is difficult to determine whether there are intentional overestimates or underestimates, or whether productivity is improving, therefore, Estimation Based on story points came into being.

Basic usage

The basic practice of story points is to give a "standard point" for some common "standard tasks" to form a comparison baseline. When estimating, as long as the task is of the same type, write the number of stories rather than the number of days. For example:

1. add, delete, modify, and query a single table

2. Add a complex report to an existing data table

3. modify a moderate-difficulty bug

......

In the beginning, "points" can be the average number of days that previously completed the task. For example, if you have added, deleted, modified, and queried a single table for four times and found that the number of days for viewing history records is about 15 days, you can set it to 15 points. In the future, if you encounter similar tasks, you can directly write "15: 00" without making detailed estimates.

 

If the story points are used for six months, assuming that the number of teams remains the same, and the number of stories completed each month is 76/82/92/81/102/98, the development efficiency is continuously improved.

Of course, not only development efficiency is the cause of change in the story site productivity, for example, testing/deployment may take some available development time at the end of the stage, resulting in a decrease in the story site. Therefore, changes in the available time are usually followed up synchronously.

Target

Some beneficial changes may occur to the Team's work after the use of story points. This is the main purpose, for example:

1. The team will compare the standard points horizontally, and thus get some motivation

Although different teams may choose different standard tasks, they will inevitably overlap. If one party sets a task as while the other party sets it as, both parties must communicate with each other.

Of course, the two points cannot be roughly considered the same, but the difference between the two reflects the difference in team productivity, it can also be considered to indicate the differences in the maintainability of both architectures and the reusability of existing modules. Reasonable Analysis and Handling of these differences will bring about positive improvements.

2. The overall estimation process is not so entangled in the differences in personnel capabilities, but in "what is this task"

As mentioned in the agile ecosystem (which will be detailed in another blog post), the goal of estimation is not a number, but a task and a method to optimize ". The story point is better than the number of days at this point.

An additional value is: if a task seems to be more difficult than a standard task, you can estimate the number of points to avoid missing obvious differences. This number difference is based on the difference in tasks, and the evaluation process of task differences is useful for determining the scope/standards/methods of this task in the future.

3. With the help of the story point productivity changes, you can observe the actual productivity changes

As mentioned at the beginning of this article, this cannot be achieved by days.

4 ....... (Any target that cannot be achieved by direct days)

If the implementation of the story points does not reach the above goals (or even do not think about the goals before the implementation of the story point), the implementation of the story points will basically fail.

Difficulties

There are few success stories in the industry in China, including:

1. The project or product features of the story point are obvious and cannot be compared across teams.

2. Without historical data, it is difficult to set standard tasks.

3. When there are not so many categories of standard tasks, it is difficult to determine which standard task a new task is like. Too many standard tasks are confusing.

 

In view of this, I think that before trying the story point, we should first use an intermediate state estimation process:

1. After each iteration, the actual completion status of all tasks is recorded and a set of historical completion status of all tasks is formed.

2. each plan will still estimate the number of days, but you can feel at any time the new task is like the previous task, and quickly find the history (print a booklet), increase or decrease the number of days in the historical data according to the task difference

This method cannot directly reach the target of the story point, but it can gradually establish a standard story set (those most frequently searched stories ), or at least it can help you visualize productivity in your mind ("oh, it would take 15 days to add, delete, modify, and query a single table ").

 

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