Press "Enter" to skip to content

抽干StoryPoint的“水分”

cheney 0

好奇怪!我经历的项目中,产品负责人(PO)无一例外都认为团队估算的故事点是有“水分”的。

他们的理由往往有下面几种:

  • 自己也是开发出身,对于事情的复杂度是有初步认识的。如果换作自己,不会估这么大
  • 基于以往迭代的估算为依据,感觉团队在当前迭代的估算上放宽了尺度
  • 有些用户故事的先决条件还未具备,从而团队对这些故事的估算过于悲观,加了Buffer

如此看法带着强烈的火药味,处理不好就会变成”You can you up!”的局面。导致的结果往往有两种

  1. 产品负责人唉声叹气,默许了团队的过高估算。以自己计划的1/3,甚至1/2开启了迭代
  2. 产品负责人强势要求团队压低故事点,全盘接受原计划来开启当前迭代

然后结果怎么样,其实不重要啦。团队习惯就好了。。。

要知道,产品负责人和团队之间的利益是有天然对立的一面。在每个迭代中(常用为两周),产品负责人希望团队能产出更多可交付的增量,从而投射到更大的投资回报率上;而团队希望能有更充裕的时间去细细考量每个任务的质量(可用性,稳定性,可持续性,等等),从而实现自我完善和提升,但在表现上或许被看作承诺更少的用户故事。

很显然,双方都有理有据。但凡对于一个约定无法度量,那一定会存在所谓的“水分”。产品负责人不可能将一个页面的需求细则至每个字体,颜色及排列,从而无法度量团队对设计调整所带来的复杂性。

如果有人对估算的准确性有极为严苛的要求,那么他需要为“可度量”这个目标付之行动。例如,以二进制的形式(要么是,要么否)来完善验收标准至用户场景百分百覆盖。更多可参考INVEST原则。在我看来,很多项目中是没有人在计划会议前有那闲工夫的。

估算永远是不准的,所以才称之为“估”算。它是建立在提问者对估算者的信任关系上而生效的。

对于这一点的认知一旦达成,结下来就是估算者一个人的事情了。换句话说,这个估算能不能准就看估算者了。如果不准,他需要自我感知并矫正。

不妨换个角度看,如果团队对于自己正在交付的产品很有信心,那么他们或许也会力求提高效率来尽早完成吧。

今天听同事说,有点水分也不错,总不能放炉子上干烧吧。

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注