Estimated value of agile
Agility is estimated that in agile development, the work is about to begin to estimate relative workload, complexity and duration. Typically, the software development process, there are many unknowns: technology updates, demand changes, dependencies between systems, which will affect the estimates, so that the estimate is a time-consuming work, and the result is also inaccurate of. That being the case, why do we need to be agile to estimate it?
- Estimates and plans are closely related, the estimated result is an important basis for the plan. Policymakers need the estimates to adjust demand priority, scheduling resources, and even cut off this feature.
- For customers, the estimates can be given on the expected lines of a function even more promise, although this is not absolutely accurate.
- Estimates of the team, gave the team an opportunity to discuss demands in advance, to establish a consistent understanding of the needs, beyond doubt.
- Estimates need to be a team in-depth study has not yet started work, think ahead will involve teamwork even cross-team collaboration, team greatly enhance the efficiency of practical work.
Although the original intention was to estimate the expected completion time, but I think this event is the most important value-depth understanding of the process of estimating the demand for the establishment of, and prior to implementation and policy features to do thorough consideration. This will play a very important role in the next practice, or even determine the entire iteration can complete the goal.
Why use story points
Estimate is a very difficult task, it is the same with all predict future events, results are often there is a huge error. Want to get accurate predictions, we need to spend more time to understand the details. The team estimates the time spent diminishing marginal benefit is inevitable, and therefore spend too much time on the estimates are quite uneconomical. How do we estimate?
Do not forget, what is the nature of human beings? Not to say that video machines!
I mean, human beings are born better at estimating relative rather than absolute estimates. Therefore, the estimated relative value will be faster and easier to understand. For example, I have before me two buildings, one is twice the height of other buildings, I can quickly determine out. But I could not draw a building is 100 meters, the other buildings are 200 meters conclusions. Therefore, agile estimation, we introduce the story points.
The story is a point on the workload, complexity or duration relative units of measurement to estimate the earliest start using the scrum and extreme programming this kind of agile methods. Because the main object is a user story estimation, it is known as story points.
This fine bar fine is necessary to look out the bars, the story is not the same point is a story point, two story unit of measurement points of what, how to become a relative estimate?
This is because the size of the point of the story is no standard. That is, each team's story point is not the same. Work on the three story points for a team that may correspond to the work of another team five points of the story. Estimated using story point, we will not say that this feature requires 100 hours to complete, but to say that this feature is eight stories point, about twice the workload of a feature story of four points.
The story points using digital count also brings a problem, it will make people naturally want to pursue precise, and this estimate is relatively conflict. Therefore, we recommend Fibonacci number (0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144) to be estimated. Because when a larger estimate of the demand, the result of our error estimate is also greater. We want to avoid this requirement tangled in the end is the story of 20-point or 21-point story, this is no meaning.
The estimated target
Since the estimated we need to achieve both fast and accurate as possible, so the estimate of object selection is also very important. Agile development, requirements are often divided into epic, features and user stories three levels, the user can split the story into tasks. So many types, to whom in the end we estimate?
First, excessive workload will lead to estimates error is too large, leading to an epic story and character is not suitable for point estimates. Secondly, it is too delicate task, then the task of estimating the time-consuming. So, by process of elimination user stories we have left. (Of course, the actual situation, sometimes we can estimate the characteristics or defects.)
How to estimate
Estimated results are part of the team, it does not belong to individuals. First, because the person in charge of a requirement is uncertain, it is the responsibility of the entire demand team. Secondly, the team decided to estimate the number of points possible to estimate more reasonable than the individual. More importantly, when estimating team together, team members discuss and share ideas for the whole team needs a growth opportunity. So, instead of a personal estimate, we recommend team estimated that the vast majority of the team members to participate in estimates are necessary.
Our common approach is to estimate the poker team estimates, specific operational procedures are as follows:
- Each team member circulated a written 0,0.5,1,2,3,5,8,13,20,40, ∞ ,? Card.
- The Product Owner is responsible for explaining to-do list needs to pick out the needs of the team members put forward their own questions, product owner answered their questions.
- Team members estimate, elect their own estimates corresponding card cover on the table, not to inform other team members.
- After all confirm their estimates we can work together to open the card, to show their estimates.
- Assessment team estimates, so that the maximum and minimum number of points given estimates of their own members are to state the reasons given in the current results, the team discussed their differences, get consistent results. (This step is especially important to discuss the process the team an excellent opportunity to share knowledge and experience.)
- Select the next story, repeat step 2.
However, since the Landlords must be online activity in 9012, and estimates this poker hand a small matter of course no longer need a paper card.
First, create a room online add estimate demand, support for multiple scoring ways (poker estimate, T-shirts estimate).
Second, the members of the rapid scoring, marking the highest minimum score, score calculation supports a variety of ways (arithmetic mean, Trimmed mean, median, mode, custom).
Third, record the final result, at any time review.
Where to find such a nice baby? FIG next sweep the two-dimensional code can!
"Plan focus"
- The story points to different teams have different definitions. So the story can not point to evaluate team performance as standard! While avoiding inflated estimate of the number of points given real estimates.
- Estimated time to ensure the participation of all members have sufficient knowledge of the subject estimate, areas of doubt must be proposed and Product Owner explanation.
- Do not over-concerned about the absolute size of the point of the story. Ensure three points of the story demand is greater than the two story points, four more than enough story a small point.
- Team unity is necessary to always adhere to the standard point of the story.
- Please use the above applet agile estimates.
Author: Worktile product manager Peng Dong Kai
Source: Worktile agile blog
Welcome to exchange more questions about technology and collaboration.
Article please indicate the source.