Shulou(Shulou.com)06/03 Report--

Introduction:

For story, a very important factor to measure its size is story point, which is not equivalent to Function Point in software workload assessment, because story point is only used to roughly and relatively estimate the size of story, while Function Point is used to measure the exact size of functional modules and to participate in formula calculation, to be clarified here.

The estimation of story point is a very deep knowledge, and we should not be careless, because if we estimate less, it will cause us to spend much more time than the estimated time, resulting in team overtime. If we overestimate, it will lead to our team is very idle, team productivity is very low, and we will face the risk of reducing resource, because this is very critical, so we must be careful in our estimation. And it has to be estimated by some experienced people, such as in our team, which is mostly done by me and one of the most senior front-end engineers.

Implementation method:

In fact, the estimation of story point should be based on historical data, which come from our past reports. We have run dozens of Sprint, and then we can roughly estimate the reasonable range of story point that our team can tolerate by comparing a number of typical sprint and then looking at the operational ability of our team.

For example, we list the following historical data report:

Taking the last five sprint (S35-S39) for example, we can compare the two columns "Planned Story Point" and "Actual Total Effort". Then combined with what happened, there is the following evidence:

(1) Sprint 39 is a very bad example, because I was on marriage leave in this sprint, so I didn't participate in the Sprint Setup Meeting, and then I didn't estimate the story point, and I didn't have time to re-review afterwards, so the whole team worked under a messy story point in advance, and everyone was exhausted. So, although planned story point is only 22, in fact, the team contributed a total of 356.5 hours to complete these assigned story and sub-tasks, so that in the last 3 days, when I saw that something was wrong, I took part in developing and writing code myself, because my main responsibility was to lead team and technical support, and rarely forced me to rush to the front line to write code. Although finally finished on time, but really tired, I later reflected on the next, this sprint should be arranged in 40 story point is reasonable.

(2) Sprint 35 is another extreme example. In this sprint, we team accepted 3 new members because they need a certain period of time and access to available accounts, permissions, etc., so this data is of no reference value.

(3) from the perspective of Sprint 36 sprint 37 sprint 38, generally speaking, these three sprint are all running stably, which is a total effort of 276.2276269 hours respectively, but the Sprint 36 training team is very busy. Even in code frozen day, we are still doing the final bug fixing. And Sprint 37, we have very high quality, ST only reported 1 defect, Sprint 38, although team is not slow, but we completed all the tasks on the last day.

So to sum up, I think 22-26 story point is a reasonable range for our team.

Summary:

When estimating Story Point, be sure to refer to historical data. The more historical data, the more reasonable the data given when allocating the total amount of Story Point. Otherwise, whether it is more or less, it will be disadvantageous to the team.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.