传统的估算方式是询问开发人员需要多长时间才能完成工作。这种方式有两个问题：第一，他们并不真正知道要花多少时间；第二，不管怎样他们都会给你一个答案。
事实证明，虽然我们对相对大小拿捏得很准，但对所需时长的估计却相当糟糕，数量巨大的超期项目充分地反映了这一弱点。
我们拙于猜测事情需要花多长的时间，但并非没有好消息，我们擅长比较两个事物并判断其大小关系，借此我们仍可得到有效的估值。更棒的是，我们还很擅长判断两相比较的大小倍数。换句话说，虽然绝对大小我们不擅长，但相对大小我们做得很棒。
窍门在于使用一个两步流程。第一步，给所有的工作项都分配相对大小值。大小值表明需要完成的工作有多少。
第二步，完成几个工作项，度量它们实际花费的时长。得到这个实测数据之后，结合指定给其他条目的相对大小值使用，预期的进度可见性也就有了。这也正是大多数scrum团队的做法。
首先，他们估出故事相对其他故事的大小值，大小为"2"的故事的大小值是大小值为"1"的故事的两倍。团队可以把最小故事的名字用做单位，如果最小故事是"登录页面故事"，那么就可以用如下方式给所有更大的故事估大小，例如"2个登录页面"、"3个登录页面"、"8个登录页面"等等。这个命名法用用没问题，只是有点笨拙。敏捷开发人员们设计了一个通用单位，可以替代登录界面使用，他们称之为"故事点"。有些开发人员比较懒，进一步简化到干脆就叫"点"。本书中我们会交替使用故事点和点，呃，取决于我们写作时的懒惰程度。关键在于，要记住团队使用故事点做单位，指定的是故事的相对大小值。
总而言之，故事点是用来度量完成故事所需工作量的相对单位。
第二步（要记得我们在此描述的流程有两个部分），团队工作1个sprint的时间并完成一些故事。此时再描述他们平均每个sprint完成工作速率的时候，就可以使用故事点了。"平均每个sprint故事点"说起来太拗口，所以就有了"速率（velocity）"的说法。如今，不需要讲"我们团队平均每个sprint完成144个故事点"，只要说"我们的速率是144"即可。它就是那样的简单、朦胧。
你的速率就是平均每个sprint所完成的故事点数量。
