什么类型的任务可以作为Sprint Backlog中的工作项包含和跟踪？
是否可以包含分析，审核和单元测试（用户故事），或者只能在Sprint积压中包含和跟踪核心编码任务？
基本上我将用户故事分解为技术任务以更新Sprint积压，并且想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。
什么类型的任务可以作为Sprint Backlog中的工作项包含和跟踪？
是否可以包含分析，审核和单元测试（用户故事），或者只能在Sprint积压中包含和跟踪核心编码任务？
基本上我将用户故事分解为技术任务以更新Sprint积压，并且想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。
什么任务可以作为Sprint Backlog中的工作项包含和跟踪？
根据Scrum指南 - >在计划会议第2部分中，团队确定任务。这些任务是将产品Backlog转换为工作软件所需的详细工作。任务应该已经分解，因此可以在不到一天的时间内完成。此任务列表称为Sprint Backlog。 因此，无论满足上述指南的任何任务都需要包括在内。
是否可以包含分析，审核和单元测试（用户故事），或者只能在Sprint积压中包含和跟踪核心编码任务？
是的，他们可以而且应该被包括在内，如果这样做会导致Backlog转换为工作软件。 Scrum NEVER建议只在Sprint Backlog中包含编码任务。事实上，Scrum要求团队实现跨职能。
基本上我将用户故事分解为更新Sprint积压的技术任务，并想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。
这听起来很可疑。只是'你'谁打破了任务？应该是整个团队在计划会议的第二部分中分解任务。同样，非编码任务可以包含在Sprint中。 只是为了给你一个现实的例子：在我的Web开发团队中，典型的Backlog有以下任务。 1.定义和发现 2.设计和创建测试矩阵 3.将单元测试写入测试矩阵 3.使单元测试通过的代码 4.测试 5.回归测试 6.调试 7.查看'使用PO的工作软件（如果需要确保这是PO想要的）
编辑
关于任务的又一点。 规划期间添加的任务应在必要时不断分解/更新/重命名。这一点的重点是添加一组透明的分解事件，这些事情完全完成后，最终会导致按照QA标准运行的软件，最有效和最有效。这些任务应该在跨职能部门进行检索和处理，不应在团队成员之间阻止。
希望这可以帮助！
您要将这些任务作为工作项进行跟踪。这样做要小心。
为什么？你开始具体化一个过程。这里有一个滑坡。一旦你开始具体化过程，你就会停止实际上敏捷并开始创建一个强制性顺序步骤的僵化瀑布。
如果您认为这些事情非常重要，以至于您必须将它们写下来，或者开发人员会忘记它们，那么您就不会让开发人员有责任保持敏捷，或者有权做出自己的决定。
你认为他们不值得信任。
分析用户故事。他们无论如何都会这样做。为什么写下来？他们会忘记吗？重点是 理解。不是文件。不是时间管理。
审查代码。你希望他们这样做。您必须创建完成此过程的文化并获得结果 奖励。
如果代码审查的结果是“你的代码很糟糕，再做一次”，那么没有人参与，除非通过命令，否则不会完成。
如果代码审查的结果是“每个人都可以学习的新的最佳实践”加上“也许你应该根据其他最佳实践重新思考”，也许人们会参与其中。
单元测试是sprint的一部分，没有任何问题或讨论。
实际上，它可能是 - 也许 - 最 冲刺的重要部分。在几乎任何其他代码之前，单元测试首先出现。你不需要说这个。事实上，说它的行为声称你的开发人员不能被信任进行测试。
当你感觉到为程序员写下任务的冲动时，你也必须仔细考虑问题的原因。
你为什么要把它写下来？他们在做什么？
这是重要的部分。
他们为什么不首先这样做？
他们没有分析？为什么不？你难以分析吗？用户是不是自己可用吗？
他们没有进行代码审查吗？为什么不？代码审查的障碍是什么？不够时间？没有足够的合作？没有足够的奖励？什么阻止他们？
他们没有进行单元测试吗？为什么不？测试的障碍是什么？不够时间？灵活性不够？没有足够的积极反馈进行测试？
为什么你觉得需要“控制”和“胁迫”你的开发者？他们为什么不靠自己这样做呢？
简短的回答是 - 无论哪种方式最适合您的团队和相关的用户故事。
例如，如果我们正在努力将一段代码重构为用户故事的一部分，我们可能会分出一个单独的任务来处理它首先进行测试。但如果它是新开发者，我们推断它将作为我们流程的一部分进行测试（通常使用TDD）。
其他示例包括有时会分开一项单独的任务，以涵盖协调与编码所花费的时间，与外部供应商的集成测试等等。 - 基本上，任何有助于弥补特定故事的谨慎和可衡量的任务（包括您拥有的一些示例）包括在上面）。
底线是每个故事应该没有一套公式，而是根据每个故事的个别需求定制任务（即使这些任务与代码无关）。
如果您在每个用户故事中为Analysis，Coding，Review，Testing等创建任务，您将接近称为Scrumfall的东西（每次迭代分为瀑布阶段）。这是Scrum的一种气味。基本上这些活动应该包含在单个任务中：“做某事”意味着做你需要的一切来完成“某事”=你是专业的开发人员而且你知道（或者政策说）完成任务需要做些什么。
这是一般情况。有时您确实需要将任务划分为“活动”，但首先应该从常见过程开始，并且只有在您有真正原因的情况下才使用此工具 - 例如一次迭代中的尖峰任务和第二次迭代中的实际任务。
编辑： 我曾将任务划分为一次。我们没有做TDD，但测试是在完成任务后编写的。因此，每个开发任务都与测试任务配对，以表明它可以由另一个开发人员完成，有时与开发并行。但是，另一个开发人员测试的责任是团队决策，而对于他们真正做到的复杂任务。
如果您将所有应用于任务跟踪的工作集中在将您的故事分成更小（1-3分），那么您将努力变得更加敏捷。小故事几乎不需要任务级别估计或跟踪。您的PO的优势在于能够优先处理较小的功能集，并且您可以专注于提供价值，而不是重复记录明显的步骤。当然，按照每个小时的小时跟踪一个团队商定的标准做法并不是很有用。