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