问团队之间的故事点正常化，有大问题吗？

EN

我已经在几个团队中尝试过这种方法，它不会导致跨团队效率的提高。我们总是使用每个人都理解的参考故事，作为基础，它有一个非1值(在我们的例子中是2)，以确保我们所知道的事情比那个参考故事更小，我们可以给出它们。

当团队被带到评估室时，这个概念就会瓦解，需要说明什么是比参考故事更大的东西。一些团队，由于某种原因，将某物视为参考故事的4倍，另一些团队则估计为参考故事的2倍。他们都是正确的，因为故事点不是几个小时。

只要团队的规模是一致的，团队的估计是有效的，并且您可以从团队实现的速度来预测。但是跨团队的比较是行不通的。团队A经常从引用中使用更大的增量，似乎总是在sprint中完成更多的故事点。B组将被评估为“低绩效”，而实际上他们只是在不同的规模上进行评估。

当我花了大约3周的假期时，这一点对我来说更加明确了，允许在我缺席的情况下进行两轮评估，由一个团队领导来管理其他团队的“更高”估计值。当我回来的时候，我们的速度突然突飞猛进，团队的所有故事点都要高得多，但我们并没有真正完成更多的工作。

(这还指出，我对小组所做估计的大小有着不均衡的影响)

总之，使用一个参考故事是非常有帮助的。组织可以理解评估过程，并感觉每个人都在标准化。但是，除此之外，我不相信团队之间的任何估计大小的一致性，除非您也让相同的人做所有的估计，并将团队从等式中删除。

这是个坏主意。根据故事点进行估算的全部要点是要有一个抽象的单元，它不能直接与时间或跨团队进行比较。你不可能通过让故事点在团队之间的大小相同来学习任何有用的信息。你需要一个相当精确的速度和整个故事点来做任何真实的比较，如果A团队估计一个200点的项目，并不一定意味着它比B团队估计的400点故事小，你也需要速度来得到一个有意义的比较。有可能是A组的4次冲刺，B组的5次。你越想让事情变得相似，就会发生更多的比较，甚至非正式地说，有些人会开始做这些比较。在任何多个团队环境中，总是会有微妙的压力，不要成为速度最低的团队，通过尝试在团队之间保持故事点的一致性，这将使这种压力更加明显。

我想知道的第一件事是:你希望这样做能得到什么？

你想找出项目的相对规模吗？嗯，我不认为这有多大帮助(除了给你一个非常粗略的猜测是大还是小)。从本质上讲，故事点只适用于估计他们的人。

故事时间有助于说明这一点。我做过的一个项目是一个网站，它大部分是CRUD页面，但有一个超级复杂的界面。这个项目应该是一个旧的大型机应用程序的替代品，他们希望他们的主页能够在处理快速键盘输入方面模仿旧系统。这个页面有大量的移动部件，在这些部分中，更改一个输入可能会启用或禁用大量其他字段，更改验证要求，隐藏或显示页面的部分，您就知道了。

我们有一个初级开发人员，他主要是前端的东西，而我来处理UI。初级开发人员可以处理HTML、CSS和一些基本的jQuery。如果她估计这会花费她的精力，那将是100+的故事要点。

在这一点上，我是一个高级开发人员，我建议我们在这个页面上使用角。我估计这份工作总共有30个点。尽管我们的初级开发人员有一个学习曲线，但我们最终以更少的努力获得了更好的UI。

整个故事的重点是，努力在很大程度上取决于做工作的人。一个经验丰富的团队可以提出更好的设计，工作更快或有较少的问题。其中有些被团队的速度所吞噬，有些则没有。

回到你想要得到的。你是想比较团队是如何工作的，他们有多好吗？因为不管你愿不愿意，我都肯定你会得到的。

当故事点相对于一个团队时，你能合理地比较一个团队的唯一东西就是它本身。对于给定的团队，您可以跟踪速度的增长、更准确的估计等。但是你不能说“A队在2周的冲刺中得到50分，B队只得到30分，为什么B队会如此懈怠？”通过记住1 Team A point =/= 1 Team B point (加上大量其他参数)，任何尝试都可以立即停止。但一旦你有办法说1分是1分跨队，现在直接比较是不可避免的。无论人们是否有意识地想要做这些比较，它们都会发生。我可以向某个地方的经理保证，他们也会这么做，并用它来宣布一个团队“表现不佳”。

我可能错过了一些东西，但我所能看到的是，这将最终带来的好处很少，并有许多潜在的不利因素。总之，不要这么做。