无国界医生敏捷:风险与故事点?

我正在为一个新项目创建一组初始用户故事,我第一次使用MSF Agile。我有大约100个用户故事,我已将它们全部分配给区域和迭代,但下一步是分配所有风险,故事点和堆栈排名值。然而,我发现我为风险和故事点分配了几乎镜像相反的值,即我所有的1-High风险故事都是3个故事点,而我所有的3-Low风险故事都是1个故事点。 MSDN文档定义了这些字段: “故事点:捕获用户故事大小的主观度量单位。如果您为用户故事分配更多分数,则表明需要执行更多工作。” “风险:成功完成用户故事的相对不确定性的主观评级。您可以指定以下值:1 - 高,2 - 中,3 - 低” 我发现这些都是我遇到的几乎所有情况都很难实现的。根据您的经验,有哪些高风险故事只有几个故事点,或低风险故事值得多点? 我需要帮助来推理这些不同的东西。我该怎么想这些?     
已邀请:
它根本不应该那样。 有可能实现一大块没有任何风险的故事。风险并不意味着它需要很长时间,相反,它比你想象的更长时间。 故事3风险1的示例可以是一组必须精心定位并且每个由客户验证的GUI。您知道这将花费很长时间,但您不希望每个屏幕超过一次或两次迭代。 故事1风险3的示例可能与您认为您知道API的Web服务器连接。可能是微不足道的,可能很烦人(如果有一些令人讨厌的cookie,你必须模仿或者其他东西 - 只是这样做,而不是个人网络开发)。 故事1风险3将会更加罕见,因为您应该更深入地检查它们并降低风险,但在某些情况下,当您完成时,您可能已经实施了它......     
只是为了让未来的读者进一步澄清...... 故事点是对任何给定特征/用户故事的大小和复杂性的估计。此外,这些值是相对的,即与功能B相比,功能A的大小和复杂程度是多少。这是一个完全不同的讨论,但迈克科恩的“敏捷估算和规划”将是一个很好的起点。 风险应该与您对给定特征出现问题的可能性的估计相关联。 所以,例如,你可能有一个需要大量“驴”工作的功能......即大量艰苦的工作,但不是很棘手或在知识领域之外。这将是一个低风险项目。 但是,如果您拥有可能看似简单的功能/小功能,请将基于表单的身份验证添加到您的Web应用程序中。由于可能需要处理Web应用程序周围的大量安全问题,或者团队中没有人具有实现基于表单的身份验证等方面的任何经验,因此可能会变得更具风险性。因此,看起来像一个小的功能添加新类型的登录屏幕&后端的身份验证可能会变得更加棘手。出现问题或丢失某些东西的风险更高。 希望这有助于澄清故事点和风险之间的区别。     

要回复问题请先登录注册