Velocity不背这个锅 (Velocity Is Not Responsible For It)

发表于2020-03-01|更新于2026-03-15|1. 质量管理

|浏览量:

【中文版Chinese Version】 NOTE： The English version can be found after this Chinese version.

01. 那些对速度（Velocity）的误解

![图片来自网络(/img/01-1024x768.jpg)

误解1 - 点数跟天数对应？

用户故事的估点跟天数对应，1个点的故事对应2天的工作量；

统计每个用户故事所耗费的天数，如果点数对应的天数到了，先标记为“开发完成”，第二天Desk check就不用增加天数了；

为了赶进度，由结对改为不结对，原来结对的两人并行做不同的task，天数还是按照结对的情况来统计…

问题：

虽然按照故事点来估算，但是每个点都跟天数对应起来，而且不是理想人天，是实际耗费人天；
把这种估算当做一种承诺，要求故事需要在点数对应的天数内完成；
用户故事的只是关注开发完成。

到底该如何估算？点数又该如何使用呢？

误解2 - 做不完了给用户故事涨点？

如果用户故事没有在预定的天数内完成，需要涨点，那么得先说服客户；

列出涨点原因并且跟客户解释不是一件容易的事情，团队有时候宁愿加班加点按照原来的估点完成也不要去跟客户解释…

或者，为了避免以后涨点的各种麻烦，在估算的时候多估一些点，导致估点不准确…

问题：

开发团队的估算不应该受到外部因素的影响；
虚估点导致的估算不准确失去了估算原本的价值和意义。

估算的意义是什么？什么时候需要调整点数进行重估？

误解3 - 速度驱动一切？

周报里的速度保持稳定，每周每对pair在2个点上下；

性能调优，客户觉得目前看不到价值不给点，所以团队就不做了；

技术改进，同样的，客户看不到价值不给点，就不做了；或者团队实在无法忍受想要改进，那就从别的功能用户故事里多估算一些点来留时间给做技术改进；

目前组内开发速度不够，用户故事都做不完了，生产环境的support能给别的组就给别的组做吧，那个太耽误开发进度了！

问题：

一切围绕速度，如果比较顺利，满足了速度要求，团队可能就放松了，不一定会做更多的特性开发；如果不顺利，速度赶不上，那就可能面临着加班或者愁着怎么能给故事涨点以增加速度；
不再是业务价值驱动，不会正常的从价值的角度去考虑工作的优先级，速度被严重的误用。

速度有什么用？又该如何利用呢？

带着这些误解中引发的疑问，我们一起来探讨一下。

02. 两种估算方法

![图片来自网络(/img/02-1024x683.jpg)

1. 基于故事点的估算

故事点是纯粹对用户故事大小的相对度量，不应该跟任何的天数或者工作量等关联。

用户故事本身的大小属性不会发生变化，基于故事点的估算不会过期，不会受到团队技术能力和业务领域熟悉度的影响而发生变化。比如，一个点数为3的用户故事，它的复杂度相对于那个点数为1的基准故事来说不会发生变化，不管谁、也不管用什么技术来开发这个用户故事。

故事点的大小是指团队所有角色工作加一起的统一估算数值，需要多个角色一起合作讨论才能得出这个估算，因此，故事点的估算方法有利于帮助团队实现跨功能合作的行为。特别注意，不应该按照开发的点数、测试的点数去估算用户故事的大小，需要结合一起给出一个唯一的数值。

2. 基于理想人天的估算

理想人天的估算需要基于这样的假设：

所估算的故事是唯一要做的工作
所有需要的东西在故事开始前都会准备好
故事开发过程中不会被打断。

在不考虑其他因素的情况下，这种理想人天的估算是类似于故事点的估算方法，同样是一种相对大小的估算。

理想时间跟耗用时间是不同的。比如一场NBA比赛的理想时间为12分钟一小节，但是实际比赛耗用时间需要比这个时间长很多，因为中间有暂停、死球等时间。理想人天的估算是基于理想时间的，在软件开发过程中会有多个因素导致实际耗用时间跟理想时间会有很大的不同，比如开会、讨论等。

理想人天的估算方法很容易让人根据一个故事所需完成的任务多少去估算，而不是从这个故事跟其他故事的相对大小角度去考虑；不同人估算的理想人天也会有不同，导致估算可能会不太准确。这在估算的时候是需要特别注意的。

在团队不熟悉故事点估算方法的初期，理想人天的估算方法更容易开始；理想人天的估算对于团队外部人员更容易解释清楚，也更方便预测速度。

哪种方法更好

从前面的介绍可以看到，两种估算方法各有利弊，都是对于用户故事大小的相对度量，不能跟实际完成天数关联起来。通常，更推荐使用故事点的估算方法，根据团队自身情况也可以选择采用理想人天。

03. 什么情况需要重估

前面提到的误解里对于用户故事没有在预定的天数内完成考虑给故事涨点，也就是重估，这种以进度来驱动重估的做法是不对的。没有在估算天数内做完可能有两个方面的原因：

估算不准确，低估了；
被其他工作所打断，或者团队技术原因导致进度较慢…

发现估算不准确的情况可能需要调整，但不能是因为做不完赶不上进度而调整。当所有用户故事的相对大小是准确的时候，不需要重估；只有当其中一个或多个用户故事的相对大小不准确的时候，需要调整该部分用户故事的点数大小。

我们来举例解释这个问题：

1. 不需要重估的情况

假设一个团队有4个复杂度相当的用户故事，原本估算均为3，预计能够在一个迭代完成的。在第一个迭代结束后，只完成了其中的两个用户故事，也就是完成了6个点，团队感觉这两个用户故事比预估的要大，想调整为原来点数的两倍，由6变成12；由于四个用户故事的大小相当，剩下的两个用户故事也需要调整为原来的两倍，剩下的工作量也变成了12，同样的可能还需要一个迭代才能完成。这样的重估就没有意义。

因此，如果只是发现用户故事实际耗费时间比原来预测的要多，但是故事的相对大小并没有问题的时候，不需要重估，而是要去回顾和分析耗费时间长的原因，并采取相应的措施去改进。

2. 需要重估的情况

假设团队由A、B、C、D四个用户故事，刚开始给每个故事的估点均为3。在开发故事A的过程中发现A比原来估算的值要大，需要调整为5才合适，另一个类似的故事B也是一样，需要调整为5；但是C和D跟它们不一样，估算值应该是准确的，还可以保持为3。这种情况下对A和B的重估是有价值的，因为相对大小发生了变化。

![图片来自网络(/img/03-1024x684.jpg)

04. 速度的作用

速度是对团队的进度生产率的度量，可以通过计算团队在一次迭代中完成的用户故事所分配的故事点数的总和来得到。比如，完成5个3个点的用户故事，速度是15；如果完成了2个5个点的用户故事，速度是10。关于“完成”的定义不能只是到“开发完成”，而应该是“交付完成”，开发完成不能说明什么，可能后续测试还不能过关、有很多缺陷需要修复等情况。

速度可以修正计划的误差。估算把对工作量的估算和对工作时长的估算完全隔离开来，将必须完成的所有用户故事的点数总和除以迭代的速度，可以推算出迭代的次数，也就是项目持续时间。我们通过一个例子来看速度如何修正误差：

假设团队估算出项目中包含了200个故事点的工作，一开始认为可以在每次迭代中完成25点，也就是将用8次迭代来完成工作。但是，在项目开始以后，团队发现速度只能达到20点。这样，不用对任何工作进行重估，就可以正确的认识到项目需要10次迭代，而不是8次。

速度不会是稳定不变的。根据团队对技术和业务领域知识的熟悉程度，速度可能会增加；而随着团队人员调整，有新人加入以后，速度可能会下降。在故事点估算准确的情况下，速度正好是反映团队状态的一个参数。不应该为了保持速度的不变去调整估算的结果，而应该根据速度的变化来观察和分析团队的健康程度。

05. 估算与计划

估算是为了更好的做计划，通过估算推算出的持续时间是一种可能性，而不是对交付时限的一种承诺。估算的是用户故事固有的属性，其大小不应该受到交付时长的干扰。老马在文章《WaterfallProcess》里讲到敏捷开发里的计划应该是适应性的，而预测性的、承诺性的计划不属于真正的敏捷。我们需要认真做好估算，尽量的准确，利用速度并根据团队状态和其他项目因素来适时地调整、修正计划。

![适应性计划(/img/04-adaptive-planning-1024x513.png)

客户都会希望更短的时间交付更多的功能，但是不要让客户只把目光关注到进度上，要引导客户更多的关注交付的业务价值。因此，在考虑任务的优先级的时候，需要以价值为导向，而不是进度为导向。比如，重构等技术改进、性能调优、生产环境的支持，这些可能比新的特性开发带来的价值更大、有着更高的优先级。

06. 小结

不管是故事点还是理想人天的估算方法，估算的都是用户故事的相对大小，跟实际完成时间没有直接关系。
不能因为用户故事没有在预期的时间内完成而进行重估，只有相对大小发生变化的时候需要重估。
估算是为了更好的计划，不能把估算当做一种承诺；速度是可变化的，可以用来修正计划的误差。
始终要以价值为导向，更多的关注质量而不仅仅是进度，计划应该是可适应性的。

07. 参考文献

《敏捷软件开发实践：估算与计划》，作者：Mike Cohn，译者：金明
《点之殇》，作者：冉冉，https://insights.thoughtworks.cn/story-point/
《WaterfallProcess》，作者：Martin Fowler，https://martinfowler.com/bliki/WaterfallProcess.html

ENGLISH VERSION:

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…

Problem:

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…

Problem:

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.

Problem:

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.

![Adaptive Planning (/img/04-adaptive-planning-1024x513.png)

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.

06 Summary

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.

文章作者: BY林子

文章链接: https://www.bylinzi.com/2020/03/01/velocity-is-not-responsible-for-it/