在敏捷过程中，故事点是复杂性而非时间的度量。这对于一个不太复杂但需要更多时间来完成的故事有什么好处。
让我举个例子，
故事 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?
我几乎对这个想法深信不疑，但想知道在这种情况下使用的最佳实践，或者是否有任何我可以阅读的好文章？
“与故事相关的故事点的数量代表了故事的整体规模。没有固定的公式来定义故事的大小。相反，故事点估计是开发一个特性所涉及的工作量、开发它的复杂性、它固有的风险等等的结合。” ——来自 Mike Cohn 的敏捷估计和规划。
在我的开发团队中，我们根据大小和复杂性来估计故事。我向新团队成员描述它的方式是将大小和复杂性视为图表上的两个正交轴。这允许复杂性不同但在相反方向上大小（努力）相同的故事被认为是相对相同的。
根据个人经验，我们发现如果只考虑复杂性，那么您的团队可能会无意中低估需要大量努力才能交付的故事。这将避开您的积压估算，并使使用三角测量等技术来保持估算的相对性变得更加困难。
我不知道一篇好文章，但这是我们使用故事点估计活动的方法：首先，我们将尽可能多的开发团队成员与产品负责人（PO，客户的决策者）召集在一起，我们让 PO 解释一个任务/故事/功能，然后我们使用计划扑克（以 PO 作为参与者）来评估任务的复杂性，因此要分配的故事点数。
这里重要的部分是，从 PO 的角度或任何开发人员的角度来看，复杂性是不同的。从 PO 来看，您给出的“更改公司名称”示例可能非常简单，但从开发人员的角度来看，它会传播到整个应用程序中，因此非常复杂。
规划扑克帮助我们建立一个框架，让每个人都表达他对复杂性的看法。对我们来说，它给出了很好的估计。
另外，请记住，您的故事点并不代表故事的复杂性，而是故事实现的复杂性。