On the second day of coaching for a development team, a team leader asked, “the boss often ask me for a development plan. How can I quickly evaluate the estimated development completion time? We currently use human-hour estimation. I've heard of story point estimation. Do you know it's suitable?”
It is learned from the person in charge of this team, the boss usually asks this question when they receive new demand for project quantity. Boss needs to know and have an estimated time for completion of new requirements. In addition, the boss is directly engaged in the traditional waterfall development project, and he is often involved in the medium and long-term plan, which is the problem of the project monument or key node that we usually talk about.
In the early stage of agile development, team members were also confused about how to estimate faster and better, and whether story point estimation should be adopted.
From the above analysis, it can be concluded that:
Firstly, the team has no idea about story points, and they need to learn about what is story point.
Secondly, the team should solve the problem of how to provide leader with the development plan.
To solve the problem, we have two steps: first solve the problem of unfamiliar story points, and introduce the definition and characteristics of story points to everyone. Then everyone understands the simple difference between the two levels of estimation, namely the product to-do list estimation and the Sprint to-do list estimation, to solve the problem of the development plan.
If you have time, it is recommended that you first read the article “Using Core Concepts to Understand Estimation” to understand the core concept of estimation. Then look at this article for better results-this article mainly tells the story points. Is there a better practice for specific estimation methods? Later, in “Using 2 Common Methods for Estimation”, we will introduce a few better estimation methods, including: Planned Poker Estimation, Agile Estimating 2.0 and so on. This article is still making skills reserves for estimation, that is, clarifying what is the story point. One of the core concepts of estimation already mentioned in the previous article is the relative size of estimation. For this relative size, we use story points as the unit. Here we focus on explaining what a story point is from the definition and characteristics of the story point, and then solve the problem of providing a plan to the leader.
Definition of story point
Story point is a unit of measurement that expresses the overall size of a story, a function, or a work. When using story point estimation, we assign a point to each to-do item. The original data of the estimated results of to-do items is not important, we only focus on the final relative estimation results. A story with an estimated value of 2 should be twice as much as a story with an estimated value of 1. But it should also be one third of the story which is estimated value of 3. The team should not use 100, 200, 300, but 1, 2, 3. The estimated result is a relative value, not an absolute value.
"When story points are used to estimate the size of a story, there is no fixed formula for how to calculate the value of story points. Story point estimation is used to evaluate the team effort involved in delivering a story, the complexity of the story, the risk, and all other elements that need to be considered. --"Agile Estimating and Planning", Mike Cohn.
Characteristics of story points
Story points are relative units
It is a relative unit. For example, different organizational teams may have different story points for the same story; even for the same team, the story points for different stories, even for the same story, are allowed to be different. But at the same time, it reminds us that the setting of story points of different stories in different teams is conducive to the accumulation of organizational energy and horizontal reference.
Story point estimation is not the same as quantity estimation
Story point estimation is not simply equivalent to quantity estimation. As described by Mike Cohn, it includes multiple value factors, such as the amount of work, technical content, and various constraints. Sometimes these other factors are more important in story point estimation than the consideration of work volume.
Story points should consider the "definition of completion"
The story points estimate must cover all the things to be completed until the product backlog is actually completed. If the team’s “definition of completion” includes the creation of automated tests to verify the story (and it is a good idea), then the effort to create these tests should also be included in the story point estimate.
In the above introduction, some friends may ask: some teams use work hours (unit hour) to estimate, can’ t it? As mentioned earlier, some mature teams can also learn from historical data and experience, and directly apply working hours or ideal hours estimates.
If it is decided to recommend the working hour (or ideal day) and when the story points are applied better, then I generally recommend using story points when estimating the product to-do list, while the Sprint to-do list estimating working hours (unit is hour).
The reason is very simple. Combined with the question raised by the person who is in charge of the team at the beginning, in fact, the boss is more interested in how many requirements can be delivered at a certain point in time (in the form of stories). The most common question is: “When can these 50 requirements be completed?” Obviously, the boss is not asking how much demand can be fulfilled in this Sprint, but is asking if the project has an estimated time point or milestone. In other words, it is necessary to make a long-term prediction of what value can be delivered at a certain point in time. If each story is estimated in an average of 15 minutes, it will take 50*15 minutes=750 minutes=12.5 hours to estimate with 50 stories. Obviously, the time cost required to estimate is relatively high, and the ROI is too low. If you use story points with similar accuracy to estimate, the efficiency will be greatly improved. I mentioned why it is easy to estimate story points, so I won’t repeat the explanation here. At this time, it is recommended that the team complete an estimation with a story in an average of 3 minutes, so the estimation will take 50*3 minutes=150 minutes=2.5 hours. In this way, according to the team’s normal rate, we can predict the completion time and answer the boss’s questions.
For the estimation of the Sprint list, the target is to determine the amount of work to be completed by the team’s Sprint, and the story points are somewhat abstract. When the team is executing, time is conceptually a bit difficult, but hours are much easier. Usually, the Sprint list items also have many less to-do list items, so it doesn't take too much time. In addition, for the items in the Sprint list, there will be more specific requirements, usually with task refinement and “completion definition”, so as to make it clear how to do it and who will do it. Taking these factors together, it is an advantage to estimate the working hours (unit is hour).
Reference:1. Mark C. Layton. Agile project management [M]. Beijing: Posts & Telecom Press.