Agile Software Development Practice-sprint Story Point estimation

Introduced:

For story, an important measure of its size is story point, which is not equivalent to the function point in the software workload assessment, because story is simply a rough relative estimate of the size of the story, and function Point is used to measure the exact size of a functional module and to participate in the calculation of the formula, which is clarified here.

The estimation of story point is a very deep learning, and we cannot be careless, because if we estimate less, it will lead us to spend much more time than estimated time, which will lead to overtime team, and if we overestimate it, we'll be free, team Productivity is so low that there is a risk of cutting resource, because it's critical, so we have to be careful with the estimates, and we have to let some very experienced people estimate that, for example, in our team, this is mostly done by me and one of the most senior front-end engineers.

Implementation mode:

In fact, the estimated story point is based on historical data, these historical data from our past reports, we ran dozens of sprint, and then we can through a typical number of sprint comparisons, Then look at the sprint of our team's ability to roughly estimate the reasonable range of story point that our team can tolerate.

For example, we list the following historical data reports:

For the last 5 sprints (S35-S39), we can compare "Planned Story point" and "Actual total effort" 2 columns. And then combine what happened, like the evidence:

(1) Sprint 39 is a very bad example, because I was in Hugh Marriage in this sprint, so I didn't take part in the Sprint Setup meeting, and then I didn't estimate story point, and I didn't have time to review again after that, So the whole team worked in a very messy story point with a predetermined estimate that everyone was paralyzed. So, although planned story point is only 22, in fact the team contributed 356.5 hours to complete the allocation of story and sub-tasks, so that the last 3 days I see the situation is not right, I have to participate in the development of writing code, Because my main responsibility is to lead the team and technical aspects of the support, rarely forced me to rush to write code. In the end, although it was done on time, but I was too tired, I later reflected that the sprint should be arranged in 40 story point to be reasonable.

(2) Sprint 35 is another extreme example, in which our team accepted 3 new members because they needed a certain amount of time to get started and access to usable accounts, permissions, and so on, so this data has no reference value.

(3) from the sprint 36,37,38, the 3 sprints are generally running 3 sprints, 276.2, 276,269 hours of total effort, but Sprint 36,team is very busy, even if the code Frozen day, we are still doing the final bug fixing. And Sprint 37, we have a very high quality, ST only reported 1 defect, Sprint 38, although the team leisurely, but we are on the last days to complete all tasks.

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

Summarize:

In estimating story point, we must refer to historical data, the more historical data, then the allocation of story point total of the data given is more reasonable, otherwise no matter how much or less, for the team are unfavorable.

This article from the "Cohesion of parallel Lines" blog, please be sure to retain this source http://supercharles888.blog.51cto.com/609344/1261146