我有一个关于 Scrum 和用户故事的快速问题。
我正在为大学做一个小项目，我决定使用 Scrum 和用户故事来解决这个功能，我知道 Scrum 通常是由一组团队成员完成的，但就我而言，我是与项目主管单独完成的。
我了解用户故事的内容以及指向和优先级系统，例如（必须、应该、可以、不会）
现在，当我即将结束迭代时，可以说大约一半的用户故事已经完成。
我的用户故事的一个例子是：
“用户需要能够记录设备”
我为这个用户故事创建了一些子任务，除了 1 个子任务之外，我已经完成了所有子任务，并且我已经完成了迭代。我给这个用户故事打了第 8 点。
现在我不确定我是否可以将此用户故事包含在燃尽图中，或者我是否要等到子任务完成后再添加到图表中。
我还想问我是否可以根据我在用户故事中完成的任务的多少来建立我的燃尽图，或者始终基于完全完成的用户故事的数量，包括测试等。
提前致谢！
有两种传统的燃尽图（Scrum 本身都不需要）：Sprint 燃尽图和发布燃尽图。
现在我不确定我是否可以将此用户故事包含在燃尽图中，或者我是否要等到子任务完成后再添加到图表中。由你决定。发布燃尽图的目的是了解剩余的内容。该功能无法发布，因此请务必非常清楚。如果这种情况持续发生，请找出原因。
速度，你已经能够完全完成的经验量，它可以帮助你知道你应该为下一个 sprint 预测什么。这个冲刺只完成了部分，所以经验主义告诉你不要再预测那么多的工作。
我还想问我是否可以根据我在用户故事中完成的任务的多少来建立我的燃尽图，或者总是基于有多少用户故事完全完成，包括测试等。 团队传统上总结剩余的 Sprint 燃尽图任务或任务时间旨在帮助您了解是否需要重新协商 Sprint 预测（向上或向下）。
我不建议尝试在 sprint 之外烧毁任务。要在发布级别燃尽任务并了解剩余的内容，您必须估计很多细粒度的细节。你解决问题的方式会改变你目前的信念，以及需要多长时间才会改变。毫无疑问，你现在也不会做你认为你会做的所有事情。
一些技巧：
燃尽图表示在任何一天的 sprint 中剩余的估计工作小时数，因此不包括 sprint 之外的任何内容。通常情况下，故事以点数估算，这反映了团队成员（在本例中为您）对该故事所付出的努力和风险。当一个故事被分解为任务时，这些任务通常以小时为单位进行估算——最佳实践是一个任务应该不超过一天或直到你的下一次每日 Scrum 的时间。
我认为您问题中的一个潜在问题可能是“我是否可以计算冲刺结束时完成的故事部分？”。可悲的是，答案是“不”。使用 Scrum 的最佳方式是对完成一个故事采取非黑即白的态度——要么完全“完成”，要么完全“完成”。没有中间立场。完成对团队的意义取决于他们，只要它是预先定义的，而不是一个移动的目标。就我而言，我们使用的规则是，如果它的“可交付质量”以 QA 成员作为裁判，则它已完成。
如果一个故事无法交付，无论它完成了 50% 还是 99%，它都会失败。没有部分功劳。如果发生这种情况，故事会以分数为单位重新估计，放回待办事项列表中，产品负责人就有机会查看她/他是否想为下一个 sprint 重新拾起它。这也是重新评估故事估计的好时机 - 一个 8pt 的故事对于一个正常规模的团队来说很大，对于一个 1 人的团队来说，它太大了 IMO。理想情况下，团队的目标故事大小应该在 2-5 点左右。最后，如果你无法完成 8pt 的故事，这表明你的速度太高了，你需要在下一个 sprint 中做更少的分数。