NOTE： The English version can be found after this Chinese version.
误解1 - 点数跟天数对应？
误解2 - 做不完了给用户故事涨点？
误解3 - 速度驱动一切？
- 《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
- 《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html
01 Misunderstandings about Velocity
Scenario #1 - Story points correspond to development days
The estimated points of user stories correspond to the number of developing days, and a story with 1 point corresponds to the workload of 2 days;
Count the number of days spent on each user story. If the number of days corresponding to the points is reached, mark it as "development completed" first, and the next day's Desk check does not need to increase the number of days;
In order to catch up with the progress, pairing was changed to not pairing. The two people who were paired did different tasks in parallel, and the number of days was still counted according to the pairing situation...
- Although it is estimated with story points, each point corresponds to the number of days, and it is not an ideal man-day, but an actual man-day;
- Treat this estimation as a commitment that the story needs to be completed in the number of days corresponding to the points;
- Team focuses only on development completion for user stories.
How should we estimate? How should the points be used?
Scenario #2 - Increase the points of a user story if it can't be finished on time
If a user story is not completed within a predetermined number of days, the points need to be increased, but the client must first be convinced to increase the points;
The reason for the increase is hard to explain to clients. Rather than explain it to the client, the team sometimes prefers to work overtime and complete the task according to the initial estimation...
Or, to avoid all sorts of problems in the future, reserve some buffers when estimating, which will lead to inaccurate estimations in the future...
- The development team's estimations should not be affected by external factors;
- The inaccurate estimation caused by the false point loses the original value and significance of estimating.
What does the estimation mean? When should we adjust the points for user stories?
Scenario #3 - Velocity drives everything
The velocity in the weekly report remains constant at around two points a week per pair;
In terms of performance tuning, the client does not see any value at present, so the team does not do it;
Technical improvements, similarly, if the client doesn't see the value and does not give a point for improving, team won't do it; or if team can't stand to improve, then will get some points from other functional stories, so leave some time for technical improvements;
Our team's velocity is too low, and we are unable to finish user stories on time, so let the production support be handled by another team, which severely impacts the development progress.
- Everything is driven by velocity. If it goes well and the team meets the velocity requirements, the team may relax and will not do more feature development; if it doesn't go well and the velocity too low, the team may be forced to work overtime or think of ways to increase story points;
- No longer focuses on business value, won't consider the priority of work from the perspective of value, and seriously misuses the concept of velocity.
What is the purpose of velocity? How can it be used?
With all these questions, let’s discuss more.
02 Two methods for estimating
1. Estimating Size with Story Points
Story points are estimates of relative size and should not be associated with any number of days or effort.
The size attribute of the user story itself does not change, the estimations based on story points do not expire, and they do not change due to the technical capabilities of the team and the familiarity of the business domain. For example, a user story with a point of 3, its complexity will not change relative to the baseline story with a point of 1, no matter who or what technology is used to develop the user story.
Story point represents a unified estimated value of all the work done by the team. It requires multiple roles to cooperate and discuss together to get the estimation. As a result, the estimating method with story points is conducive to the achievement of cross-role collaboration. Particularly, we should not estimate a user story according to development and testing points, but should consider both and give an appropriate value.
2. Estimating in Ideal Days
When estimating in ideal days, you assume
• The story being estimated is the only thing you’ll work on.
• Everything you need will be on hand when you start.
• There will be no interruptions.
-- Agile Estimating and Planning, Mike Cohn
Without taking other factors into account, this ideal man-day estimate is similar to the story point estimate, which is also an estimate of relative size.
The ideal time is different from the elapsed time. For example, the ideal time for an NBA game is a 12-minute quarter, but the actual game takes a lot longer than this time, because there are time-outs, dead balls, etc. in the middle. The estimation of the ideal man-day is based on the ideal time. In the software development process, there are many factors that cause the actual time consumption to be very different from the ideal time, such as meetings, discussions, etc.
The method of estimating in ideal man-days makes it easy for people to estimate based on the number of tasks that a story needs to complete, rather than from the perspective of the relative size of this story and other stories; Estimates may not be accurate. When estimating, it is important to pay attention to this.
When the team is not familiar with the story point estimate method, the ideal man-day estimate method is easier to use; And it is easier to explain to people outside the team and more convenient to predict speed.
Which method is better?
From the previous introduction, we can see that the two estimation methods have their own advantages and disadvantages. They are both relative measures of the size of the user story and cannot be related to the actual completion days. Usually, the estimate with story points is more recommended, and the ideal man-day can also be selected according to the team's own situation.
03 When do we re-estimate?
In the misunderstanding mentioned above, the user story is not completed within the predetermined number of days to consider increasing the story's point, that is, re-estimate. This kind of velocity-driven re-estimate is not correct.
There may be two reasons for not completing within the estimated number of days:
- The estimate is inaccurate and underestimated;
- Interrupted by other work, or due to some technical reasons of the team...
Inaccurate user story estimates may require adjustment, but not because the user story cannot be completed on time.
When the relative size of all user stories is accurate, no re-estimate is required; only when the relative size of one or more user stories is inaccurate, the point of this part of the user stories needs to be adjusted.
1. When Not to Re-Estimate
Suppose a team has 4 user stories of similar complexity, and the original estimates are all 3, which are expected to be completed in one iteration. After the first iteration, only two of the user stories were completed, that is to say, 6 points were completed. The team felt that these two user stories were larger than expected and wanted to adjust to twice the original points, 6 becomes 12. Since the four user stories are of the same size, the remaining two user stories also need to be doubled, and the remaining workload also becomes 12, which may take another iteration to complete. Such a re-estimate is meaningless.
Therefore, if we just find that the user story actually takes more time than originally predicted, but the relative size of the story is not a problem, there is no need to re-estimate, but to review and analyze the reasons, and take appropriate actions to improve.
2. When to Re-Estimate
Suppose a team has four user stories A, B, C, and D, and the initial estimation for each story is 3. During developing story A, we find that A is larger than the original estimated value, and it needs to be adjusted to 5. The same is true for another similar story B, which needs to be adjusted to 5 as well; but the estimated value for story C and D is accurate and can be kept at 3.
The re-estimate of A and B in this case is valuable because the relative sizes have changed.
04 Why does velocity matter?
Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration.
For example, if the team completes 5 stories each estimated at 3 story points, their velocity is 15. If the team completes 2 five-point stories, their velocity is 10.
The definition of DONE should not be just "development completed", but "delivery completed". The completion of development does not indicate anything, and the subsequent tests may fail, and there may be many defects that need to be fixed.
The beauty of a points-based approach to estimating is that planning errors are self-correcting because of the application of velocity. Estimating completely separates the estimation of effort from the estimation of duration. Dividing the sum of the points of all user stories that must be completed by the velocity of the iteration can calculate the number of iterations, which is the project duration.
Let's see how velocity corrects errors with an example:
Suppose a team estimates a project to include 200 points of work. They initially believe they will be able to complete 25 points per iteration, which means they will finish in eight iterations. However, once the project begins, their observed velocity is only 20. Without re-estimating any work they will have correctly identified that the project will take ten iterations rather than eight.
A team’s velocity will not be constant. It may increase because the team gets more familiar with technology and business domain knowledge; it may decrease as the team adjusts and new members join.
With accurate estimates with story points, velocity is precisely one parameter that reflects the state of the team. We should not keep the velocity constant by adjusting the estimates, but we should observe and analyze the team’s health according to the changes in velocity.
05 Estimating and Planning
Estimation is for better planning, and the estimated duration is not a commitment. User stories have inherent estimating properties, and their size should not be affected by delivery time.
"Adaptive planning is an essential element of agile thinking."
-- Martin Fowler, WaterfallProcess
Martin Fowler mentioned in his article "WaterfallProcess" that agile development plans should be adaptive, rather than predictive and committed.
We need to estimate as accurately as possible, using velocity to adjust and revise the plan as needed based on team status and other project factors.
Clients all want to receive more functionalities in a shorter timeframe, but don't let them focus solely on the delivery progress, and encourage them to pay more attention to the business value delivered.
So, prioritizing tasks should be value-driven rather than progress-driven.For instance, technical improvements such as refactoring, performance tuning, and production support may be more valuable and more urgent than developing new features.
- Regardless of whether it is estimated by story points or ideal man-days, the estimation depends on the relative size of the user story, which is not directly correlated to the actual completion time.
- Do not re-estimate if the user story is not completed in time, only when the relative size changes.
- Estimation is for better planning, not as a promise; Velocity is not constant, and can be used to correct errors in planning.
- Keep a value-oriented attitude, emphasize quality over just progress, and have plans that are adaptable.