怎样对一个产品编写完整的用户故事( 四 )
■网友
故事点这个概念大家应该很了解了，实际上就是对在sprint里面要开发的user story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量），但是这里有个容易引起混淆的地方，就是传统意义上的敏捷，是用来度量规模和复杂度。
使用‘规模’和‘复杂度’这两个词，是要表达‘用完成任务所需时间来表示难度’。
从上面可以看出，由于故事点是对于规模和复杂度的估算，所以，第一它是一个不精确的值，第二，它应该是一个相对的值。由此来看，故事点是一个粗略的相对估算而不是精确估算。
1故事点的估算目的是什么呢？
作为PO来讲，他在梳理ＰＢＩ和ＳＢ的时候，可能是想知道团队多久能交付产品，每个迭代能够交付多少用户故事，所以故事点可以解决ＰＯ的这个困惑。我们可以通过估算故事点，然后统计多个迭代团队交付的故事点数，以此相对的得到一个团队的交付能力，比如说每个迭代交付２０个点的用户故事，那么如果PO有一个由100点用户故事组成的产品，那么可以得知5个迭代完成这个任务。
也可以得到团队的交付速率和交付能力的历史数据，用来进行团队回顾的数据依据。
在估算的过程中，因为所有团队成员都要参与，大家对于故事的理解不一样会造成估算的不同，这样就需要PO和团队成员之间进行需求的澄清，也是一个分析用户故事需求和澄清的过程，能够让大家更好的理解用户故事。
2故事点的估算的到底是工作量还是复杂度？
在实际开发环境中，大家往往会有一个理解上的难点，到底故事点估计的是工作量还是复杂度呢？
从PO角度来讲，肯定需要得到的是工作量，这样也能第一时间知道产品开发的进度还有风险，但是如果估计的是工作量的话，和实际开发的人是有关系的，因为同样一个特性，对于熟练工和新手的工作量是完全不同的。
如果只是作为复杂度来估计的话，那么产生的问题是：产品开发的复杂度在不同团队和不同人员之间也是不一样的，而且在现实开发环境中，对于复杂度的操作很难进行，有的时候大家会觉得费时费力。
从我个人来讲，在敏捷不断演进的过程中，现在故事点实际上是一个综合的对于用户故事的复杂度，规模，甚至还要加上承诺时间的一个度量了。
也就是说团队可以不必过度纠结在用户故事的度量上，而是重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的ＤｏＤ来完成这个用户故事，如果不能完成，给出理由，由ＰＯ来决定是否拆分或者重新设计用户故事。
这样带来的一个问题可能是ＰＯ在梳理ＰＢＩ的时候无法得知整个产品的全部完成时间，因为团队的历史交付数据可能不是一个稳定的速率（每个ｓｐｒｉｎｔ交付的点数差别会比较大，因为更注重用户故事本身和交付承诺）
3怎样在计划会议中更好地运用故事点估计？
如果是一个新的团队，那么建议针对用户故事进行估点，这样能够使得团队尽快熟悉起来，澄清需求，建立很好的沟通机制。 如果是一个很成熟的团队，对于产品比较熟悉，那么这个时候故事点估计就不是十分必要了，因为大家都很熟悉产品特性，所以对于所需的工作量也是相对准确的，这个时候可能就需要团队给出工作量的估计，让ＰＯ对于产品的开发更好地进行进度和风险控制。 如果可能的话，针对不同的用户故事类型设计不同的基准故事点，比如说开发的故事基准和测试的故事基准，实际上的工作量和复杂度是完全不一样的。
■网友
在工作中，多数人都只是一个被动的执行者。比如，现在让你调查北京市近期卖了多少小龙虾，没有人告诉你为什么要做这件事，你可能会理解偏差，以至于提供错误的数据，甚至对于领导指派给你这种“毫无意义”的工作感到不满。
如果换个说法：作为水产供应商，我想要了解近三个月北京市小龙虾的销售情况，以便安排后期的货源。这种说法是不是明确多了？
推荐阅读
- 聪明人养花，这3种“花”怎样也要养一盆，每年能省不少医药费
- 同比■同比增长7.1%！2021年的第一个节你花了多少钱？
- “他是我第一个会说普通话的老师”：一对师生折射青海山村蝶变
- 旅行社@旅行社推出“高铁+旅游”新产品 高铁旅行说走就走！连淮扬镇高铁全线通车
- 广西鹿寨贫困户玩直播带货变身创业新星以电商帮老乡卖滞销农产品
- 黄金时间■黄金时间丨哪种产品最节水？购买产品请注意这个标识！
- 货币等各类金融产品彻底电子化会到来么
- 有必要重新开个C店吗
- 互联网怎样解决“家政服务上门速度慢”的问题
- 怎样看待从1月8号起，QQ钱包开始提现收费