在敏捷过程中，故事点是衡量复杂性而非时间的衡量标准。这对于一个不太复杂但时间更长的故事来说有什么用呢。
让我举个例子，
故事1 ：保存用户详细信息。
Story points = 2. Typically Takes about 1 day to complete.
故事2：公司名称已从X更改为Y，需要在应用程序中进行更新。大约有40个屏幕，10个报告，法律声明所有这些都应该改变。
这是一个简单任务的典型示例，但它需要花费大量时间来实现（考虑到本地化应用程序，即使遵循适当的开发标准）和测试。
如果按照传统的定义，我会给故事点1，但后来我看错了速度，即使做好工作，速度也会下降。我看过这篇关于这个问题的文章。
My question is how this task can be compared to the first story and should the effort be included in story point estimation?
我几乎确信这个想法，但想知道在这种情况下使用的最佳做法，或者是否有任何好的article我可以阅读它？
答案 0 :(得分：5)
“与故事相关的故事点数代表了 整体大小的故事。没有用于定义的公式 故事的大小。相反，故事点估计是合并的 开发功能所涉及的工作量，复杂性 开发它，它固有的风险，等等。“ - 来自Mike Cohn的敏捷估算和规划。
在我的开发团队中，我们根据 和 的复杂程度估算故事。我向新团队成员描述的方式是将大小和复杂度视为图表上的两个正交轴。这允许故事的复杂性不同，但在相反方向上的大小（努力）上的差异相同，可以认为相对相同。
根据个人经验，我们发现如果只考虑复杂性，那么您的团队可能会无意中低估需要付出大量努力的故事。这将避免您的积压估计，并使使用三角测量等技术更难以保持估计相对。
答案 1 :(得分：3)
我不知道一篇好文章，但这里是我们如何使用故事点估算活动： 首先，我们与开发团队尽可能多的人组成产品所有者（PO，来自客户的决策者），我们让PO解释任务/故事/功能，然后我们使用计划扑克（与PO作为参与者）评估任务的复杂性，以便分配故事点的数量。
这里的重要部分是从PO的角度或从任何开发人员的角度来看，复杂性是不同的。从PO中查看时，您提供“更改公司名称”的示例可能非常简单，但非常复杂，因为从开发人员的角度来看，从整个应用程序进行传播。
规划扑克帮助我们建立一个框架，让每个人都能表达他对复杂性的看法。对我们来说，它给出了很好的估计。
另外，请记住，你的故事点并不代表故事的复杂性，而是故事实现的复杂性。