团队可以在迭代开发计划中添加任何类型的工作。如果某个特性需要进行架构研究，那么将它的用户描述添加到计划安排中并具备 “设计”、“构建原型” 或 “调研” 等任务。向发行版计划安排中为架构研究添加用户描述的优点是允许产品所有者对用户描述指定优先级。如果产品所有者认为这种研究的成本太高，那么应当将架构研究描述放到列表中优先级较低的位置，否则该特性将从发行版中移除。

为用户描述分配描述点

在产品计划安排和发行版计划安排中，开发团队将评估每个用户描述并为其分配描述点。为什么要使用描述点，而不是小时之类的时间单位？主要原因是在开发的早期阶段，您并不了解您需要为某个描述完成的实际工作量。并且，如果您提前完成了所有分析和设计工作，那么您的设计可能不会随着您对该特性的进一步了解而发生改变。

使用描述点而不是时间单位的另一个原因是，对于不同的人来说，所需的时间是不同的。如果进行评估和实际实施是由不同的人完成的，那么所作的评估可能就是错误的。

使用描述点的最后一个原因是理想时间评估最初可能会被错误地解释为过期时间评估。过期时间 指在考虑到员工在日常工作中所遇到的所有中断后完成任务所需的实际时间。因此，比如，估计可在 5 天内完成的任务，如果考虑到日常会议、电子邮件、电话呼叫和复查后，实际上需要 8 到 9 天的时间才能完成。

在使用描述点时，您实际所做的工作就是比较每个特性的相对复杂性。如果某个描述包含一个描述点，并且将它与拥有 5 个描述点的描述比较，那么实际上得出的比较结果就是第二个描述所含的工作量是第一个描述的 5 倍。注意，这并不一定表示完成第二个描述所需的时间是第一个描述的 5 倍。

由于存在太多未知的因素，团队可能无法对某些用户描述作出评估。在这种情况下，团队可以在计划安排中新增一个用户描述，进行额外的研究。完成研究后，团队可以重新审视描述来指定描述点。

在最开始的阶段，评估描述点可能比较困难，因为团队无法获得任何参考。在完成了大量评估后，评估将变得越来越准确。要执行描述点评估，可以使用 Planning Poker 技巧。

Planning Poker 是一种基于共识的评估方法，可以评估软件开发中完成某些任务所需的工作或任务的相对大小。这种方法将试图最小化锚定操作（anchoring）（团队成员在早期注释中表示为 “锚定” 任务时间）。所有团队成员将玩一套评估纸牌（评估纸牌的牌面包括 0、0.5、1、2、3、5、8、13、20、40、100，但是没有计量单位；单位由仲裁者决定），其他玩牌者不能看到纸牌的内容。当所有玩牌者出完牌之后，所有纸牌的牌面都将公布出来。

计算开发进度

开发进度 指长期跟踪团队在每次迭代开发中已经完成的工作量。它使用与发行版计划安排相同的衡量单位，即描述点。

团队首先为发行版计划安排中的每个用户描述分配描述点。在每次迭代开发的早期，团队将选择一些将在迭代开发过程中使用的描述。要获得为描述分配的描述点，团队必须完成该描述在迭代开发中的所有任务。

如果团队没有完成某个用户描述的一个或多个任务，那么对于该描述，在当前迭代开发结束时团队只能获得 0 个描述点，而该描述将被延期到下一次迭代开发中。如果团队在迭代开发中完成了该描述余下的任务，那么团队将获得此描述的描述点。

团队完成迭代开发后，将计算描述点，并查看此前的迭代开发的数据，将呈现一幅如图 3 所示的图片。注意，团队在每次迭代开发中为何没有获得相同数量的描述点。

开发进度的一个优点就是在完成一些迭代开发后，可以开始使用跟踪图表中的数字来推算您有能力完成的发行版计划安排中剩余内容项的数量。

表 1 展示了每次迭代开发中的描述点。使用表 1 中的数据，您可以推算出以下这些信息：