故事点估算可信吗？

[1000copy]

故事点这个概念，看起来鬼鬼祟祟的。

提到故事点，必然讲到，“不是基于时间的度量（如小时或天数），而是一种相对的估算方法，用来比较不同用户故事的复杂性或工作量”。

谁懂你为什么不用具体时间，而是用相对量？

敏捷联盟不是鼓励勇气和以客户为中心吗？客户真的看到你的故事点，然后如何和他的时间期限比较呢？

我问过一个行业内标杆实践企业的员工，当你估计了一个故事点的点数后，你怎么估计它的时间？

他说，我们项目组约定好，都是一个点就是一天。

这不是障眼法？…干脆一点，你这个月底能不能完成？当你故作专业的时候，客户就只能流氓起来。

我一度以为这个肯特贝克的发明，因为故事点和故事两个概念太接近了。因此我有点怀疑肯特贝克了，然而不是，我查了下，是 Ken Schwaber 和 Mike Cohn 主要再说。好像他们两个都是搞 Scrum 的。

确实，在《极限编程解释》一书中，肯特贝克并没有直接介绍故事点（ Story Points ）这个概念。

你看，敏捷联盟如果剿灭董卓的 18 路诸侯一样，也不是铁板一块。

https://projectmanagercc.github.io

[kingbill]

因为在实际执行的时候，同一个工作量的不同工作可能会用不同的时间。
故事点估算只是估算的工作量，而不是完成工作用的时间，而且是按倍数类比估算
可以先把《 Scrum 精髓》看一遍，再来回看你的这些问题

[tilv37]

实际运行的时候，至少我们这里还是对应到了一个故事点等于 XXX 小时，换汤不换药。[狗头]

[1000copy]

@kingbill 老板或者客户问你啥时候拿得出来？我猜你会这样回答：“我们估计了故事点，点数是 xx 。你去看看《 Scrum 精髓》自己就可以换算为时间了”。

[1000copy]

@tilv37 是的。所以说是障眼法。。。

[kingbill]

@1000copy 我说它不一样，你非要认为它是一样的，可能故事点是啥并不重要了，你就按你想的用就行了……（而且我上面告诉你故事点是啥了）

[1000copy]

@kingbill 所以你的故事点如何换算成时间呢？