我们开始了一个将使用Scrum / XP管理的项目。我们预先编写了整个产品backlog用于评估目的。我们确保所有故事都以客户为中心，我们正在通过
进行评估100个故事点可能会有一些故事会有/将不会有，因为它们实际上是更大的复杂故事，如果需要将在以后细分。
计算故事重要性是基于价值和努力而不重叠的MoSCoW故事。
但是，如果没有100个故事，我们的故事到目前为止（也已经细分）的复杂程度在2到8之间，我们认为这是一个适当的故事大小，以避免微观管理。但有些故事相互关联或相互依赖。我们的故事如果先完成可能会花费更多，如果在他们面前完成其他故事则会减少。
问题
是否有可能在开发过程中稍后调整故事点，因为我们可以处理故事任务，我们可以在其中重新评估它们，添加新的，删除现有的或故事不是这样的情况？因为改变它们的复杂性，也将根据计划的速度改变结束日期估计。在这种情况下，最佳做法是什么？
答案 0 :(得分：5)
你绝对可以再次估计你的故事，你应该这样做。这些积分仅在团队在Sprint开始之前的Sprint计划会议中向他们提交时锁定。
我使用的一种做法是在进行单独的Sprint规划时，您应该再次评估每个故事。团队会随着时间的推移而学习，并通过估算和识别依赖关系变得更加准确。记住Sprint的内容取决于团队，产品所有者定义整体积压。如果项目有时间限制，请不要试图使估算符合结束日期，如果你这样做，那么你就是在为失败做好准备。
请记住，使用Velocity，您首先要猜测您可以完成的任务。通常直到第3或第4个Sprint才能识别出团队可以管理的真实速度。是的，这意味着你可能认为球队每次冲刺可以得到20分，实际上只能得到15分。是的，这意味着交货时间结束或故事低于切割线。
至于依赖性故事，您应该与产品所有者合作。如果团队与他们交谈，您通常可以重新安排故事。大多数人都接受那些告诉他们的人“如果我们现在做A，那将需要完整的Sprint，但是如果我们以后做A，那将需要15％的Sprint”，这使得它非常有说服力。
尝试一种有用的做法是在Sprint中安排故事。在计划会议期间，一旦所有故事都经过验证和讨论，团队就会提取日历并讨论他们何时完成任务。通过在日历上放置目标日期，它有助于识别故事之间的重叠和依赖关系。这可以识别串行的内容，并可能导致Sprint失败。
希望这些信息有用。
答案 1 :(得分：2)
根据你的解释，你已经做得很好。当然，总有一些依赖的故事。有些甚至可能没有直接可见的客户价值;即建立架构和一些框架的最初努力。但如果你把它们排除在外，你将会产生很多技术债务。如果可以，我建议您尝试使方程完整，并以某种方式显示任务之间的关系。
例如： - 任务3如果在任务2之后完成则为8分，但如果独立完成则为12分。
这样，产品所有者会感到忽视依赖关系的痛苦，但仍然可以选择先做最有价值的故事。如果产品所有者确信所有故事都在下一个冲刺中进行，那么您可以引导他们以最有效的顺序实现它们。例如，通过阻止尚未满足依赖关系的项目（即，在故事“webenabled version”完成后，您只能在“网站上更改我的徽标”功能。）
祝你好运！答案 2 :(得分：0)
我只能描述我的经验。
当我们计划第一次冲刺时，我们决定可以完成18分。所以我们采取了几个故事，总估计为15分。正如我上面提到的那样，我们在scrum中迈出了第一步，这就是为什么我们认为3个未使用的点和0.6的形状因素保证了我们的成功。
但我们对每个故事的估计只是近似的。我们也有一些依赖故事。而且我们没有制定每个故事的实施计划，因为我们认为它对敏捷方法论是不可靠的。
结果我们第一次冲刺失败了，只有8个完整点。
在我们第二次冲刺之前，我决定从旧的简单级联和迭代方法中获取一些东西（我是一个scrum-master）。因此，在我们计划进行正确估算的下一个春天，我们计划每个故事（每个故事约20分钟），简单的图表，所有依赖关系，实施细节等等。规划很困难，需要2次会议。
但是第二个sprint要好得多，我们几乎完成了所有（实际上我们已经完成了所有但是有一些错误）。我认为我们将在第三次冲刺中采用更少的外形，并且它会成功。
答案 3 :(得分：0)
有一些模式可以帮助您以一种他们将保留INVEST的方式拆分用户故事，这意味着您将尝试特别保存依赖关系，大小，可测试性和值。你可以在这里阅读更多相关信息：http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/理查德正在积极地应用和改进它们，而且他并不孤单; - ）
请注意，拆分和保持依赖关系（就像在甘特图中创建关键路径一样）将胜过团队创造性的能力，并就这些故事进行谈判，也可能隐藏“非贵重命题”。
HTH
ANdreaT