您是否应该在Scrum积压中包含非开发任务？

Question

我们无法将某些类型的任务合并到我们的产品和sprint积压工作中：

• 与客户会面
• 培训和知识共享
• 管理任务

其中一些与项目没有直接关系，因此很容易将它们放在一边并将它们称为管理开销（从而减少冲刺中可行的故事点）。

然而，某些任务（通常是客户会议）经常发生或非常频繁。应如何处理？它们通常不直接与任何特定用户故事相关，但它们对项目至关重要。

Answer 1

在我看来，“任务”并不真正属于产品Backlog，产品Backlog项目（PBI）应该用于最终用户可见的东西 - 或者必须用于实现这些项目 - 并在展示其商业价值的方式。

会议，管理任务等周期性事件与PBI的这个定义并不完全匹配，我不会将它们包含在Product Backlog级别。实际上，我根本没有看到跟踪它们的意义（它听起来像无用的开销，即通常是浪费），因此我只是将它们包含在整体速度中。它只是有效。

非经常性事件，如特别会议，R＆amp; D，探索等，并不真正属于PB（PO应如何评价它们并优先考虑它们？）我更愿意包括它们的“成本”估计相关的PBI。当项目被选中时，我们在Sprint Backlog中创建一个相应的任务，并进行时间框估算。

我们处理假期等培训。如果团队成员进行某些培训，则会影响团队成员分配（例如90％），从而影响Sprint开始时计算的整体团队能力。我们收集的物品较少。

Answer 2

任务与产品待办事项无关。任务与sprint backlog有关。您描述的活动不是任务。

当我们计划下一个冲刺时，我们总是通过所有假期和培训减少计划容量。我们还通过“管理开销”来减少容量。在我们的案例中，管理费用通常是每周每个团队成员1MD。这笔费用用于会议，并可协助维护已部署的项目。

修改

我认为你永远不应该在春季积压中为会议，演示等创建任务。为什么？因为每个任务都有一些影响当前冲刺的估计。在sprint期间，任务实时完成，并根据该燃尽图显示团队在提供客户价值方面的进展。客户从会议中获得什么价值？此外，这样的任务可能与具体的用户故事无关，那么在产品燃尽图中可以看到哪些进展？当您必须计算其复杂性（故事点）中未包含的值时，您如何决定下一个sprint应该拍多少用户故事？

将此类虚拟任务（没有附加值的任务）添加到sprint backlog中也会影响您的速度。看起来每个故事点的成本都超过现实，因为会议时间将包含在实际工作中。

您希望将什么类型的会议添加到您的sprint积压？ SCRUM只需要几次会议 - 每日会议，计划会议，审查会议，回顾会议以及SCRUM的大型项目SCRUM。每日会议很短，不必包含在计划中。计划会议，审查会议和回顾会议不必包括在sprint中。 SCRUM的SCRUM是特定的，它不会影响整个团队 - 可以减少参加会员的计划能力。不再需要召开会议。 最重要：完成任务所需的通信是任务估算的一部分。

如果您需要其他会议，只需减少您的容量。如果客户，管理层或产品所有者抱怨小容量，只需解释它是因为非标准的管理或官僚主义开销。

Answer 3

在我的上一个项目中，我们将一些活动带到了我们的scrum板上。他们不在产品积压中，但我们在计划游戏中发明了它们。

我们包括的活动包括客户研讨会，发布活动等。

我们将它们包含在我们的scrum board中的原因是让团队中的任何人都可以看到其他人正在做的事情，并且在某些情况下也将任务分配给不在另一个关键任务中的人。

Answer 4

典型的重​​复任务被估计/速度吸收。像站起来的会议，正常的开发人员的互动，停顿等......

对于与构建产品无关的其他事件，我更愿意从开发人员的可用性中删除该时间以获得正确的容量。

因此，我们可以计划的用户故事数量取决于他们的估计，团队速度，当然还有容量

Answer 5

我的观点是，如果这些任务与培训等功能没有直接关系，则不应将其包含在产品待办事项中，而应调整开发人员的可用时间，从而调整迭代的速度。这不是因为你有一个40个小时的工作周，你可以期望人们在项目上工作40个小时。

Answer 6

如果会议或其他非开发任务与实现sprint \ iteration \ project的目标直接相关，那么我就没有问题，包括sprint backlog \ iteration计划。如果没有别的办法，那么通过提高他们的知名度来确保完成任务是有帮助的。

Answer 7

在Scrum中没有用于决定用户故事的修复公式。在我的项目中，我们选择应将哪个工作项转换为Stories。例如。比较2-3 IDE开发工具的任务在Backlog中，因为它与开发直接相关。但除此之外，我计划每个团队成员每天开展5小时的开发活动，以便他们花费剩余的时间参加培训，文档，知识交流，同行编程等。这对我来说有助于证明演示与冲刺速度。

Answer 8

如果你没有在你的积压中包含人们需要做的事情，你会如何建议管理它们？

非开发计划需要时间，而且它们对于提供优质产品与开发和工作同样重要。

您可以选择对这些项目使用单独的积压工作，或者将它们放在单独的项目计划中，但是您正在使用两个工作积压工作，并且排序和计时成为问题。

我通常强迫团队为非开发活动创建故事，例如作为产品经理，我需要制定路线图，或者作为产品经理，我需要设置技术研讨会审查积压，以便开发团队能够理解这些功能。

这实际上取决于具体情况，但如果积压是捕获和管理工作的中心位置，那么为什么它只用于开发和QA工作？

Answer 9

您可以在Trello板中管理非开发任务。这些可以是研究活动或拉动用于开发的数据。这些不属于JIRA或Rally，因为它们不是开发任务，也没有故事点估计。