我们在将某些类型的任务纳入产品和冲刺待办事项方面遇到了困难：
- 与客户的会议
- 培训和知识共享
- 行政任务
其中一些与项目没有直接关系，因此很容易将其搁置并将其称为行政开销（从而减少一个冲刺中可完成的故事点）。
但是，有些任务（通常是客户会议）是经常性的或非常频繁的。这些任务应该如何处理？它们通常不直接相关于任何特定的用户故事，但对于项目至关重要。
你是否应该在Scrum待办事项清单中包含非开发任务？
17
- Damovisa
1
3我正在投票关闭此问题，因为它与编程无关。 - Vadim Kotov
9个回答
14
在我看来，“任务”并不真正属于产品待办列表（Product Backlog），产品待办项（PBI）应该用于那些对最终用户可见或者实现这些项目是必要的，并且以展示它们的业务价值的方式表达。
像会议、行政任务等经常发生的事件并不符合 PBI 的定义，我不会将它们包含在产品待办列表的级别中。事实上，我觉得追踪它们没有任何意义（听起来像是无用的开销，即通常的浪费），因此我只会在总速度中加入它们。这种方法很有效。
非周期性事件（如特别会议、研发、探索等）也不真正属于产品待办列表（PB），（PO 如何评估它们的价值并对它们进行优先排序？）我更喜欢在相关 PBI 的估算中包括它们的“成本”。当选择该项时，我们会在 Sprint Backlog 中创建相应的任务，并进行时间限制的估算。
我们像处理假期一样处理培训。如果团队成员参加某些培训，则会影响团队成员的分配（例如90%），从而影响在Sprint开始时计算的整体团队容量。因此我们会减少选择的待办事项数量。
- Pascal Thivent
2
+1 对于重复任务来说，它们是整体速度的一部分，而不是需要跟踪项目进展的任务。 - eglasius
+1 它们不是速度的一部分，但不考虑它们是愚蠢的。为了让项目经理了解公司其他部门对开发人员造成了多少无生产力的时间，有一个关于重复和非重复事项的 X 小时的 0 点任务是有意义的，这可以给他一些实际的指标。 - corsiKa
7
任务与产品积压无关。任务与冲刺积压有关。您所描述的活动不是任务。
当我们计划下一个冲刺时，我们总是将所有节假日和培训的计划容量减少。我们还通过“行政开销”减少了容量。在我们的情况下，每个团队成员每周的行政开销通常为1MD。这种开销用于会议以及可能需要在已部署的项目上提供维护方面的协助。
编辑：
我认为您永远不应该为会议、演示等在您的冲刺积压中创建任务。为什么？因为每个任务都有一些估算，这会影响当前的冲刺。在冲刺期间，任务是在实际时间内完成的，并基于此燃尽图显示团队在交付客户价值方面的进展。客户从会议中获得了什么价值？此外，这样的任务可能与具体用户故事无关，因此，在产品燃尽图中将看不到任何进展。当您必须考虑未包含在复杂性（故事点）中的价值时，您如何决定下一个冲刺应采取多少用户故事？
向您的冲刺积压中添加这样的虚拟任务（没有增加价值的任务）也会影响您的速度。它看起来每个故事点的成本都比实际情况更高，因为会议时间将包括在实际工作中。
您想要向您的冲刺积压中添加什么类型的会议？SCRUM只需要少数会议——每日会议、计划会议、审查会议、回顾会议以及在较大的项目中的SCRUM of SCRUM。每日会议非常短，不必包含在计划中。计划会议、审查会议和回顾会议不必包含在冲刺中。SCRUM of SCRUM是特定的，它不影响整个团队——可以从参与成员的计划容量中减少。不需要更多的会议。最重要的是：完成任务所需的沟通是任务估算的一部分。
如果您需要其他会议，请简单地减少您的容量。如果客户、管理层或产品所有者抱怨容量太小，请简单地向他们解释这是由于非标准行政或官僚开销所致。
当我们计划下一个冲刺时，我们总是将所有节假日和培训的计划容量减少。我们还通过“行政开销”减少了容量。在我们的情况下，每个团队成员每周的行政开销通常为1MD。这种开销用于会议以及可能需要在已部署的项目上提供维护方面的协助。
编辑：
我认为您永远不应该为会议、演示等在您的冲刺积压中创建任务。为什么？因为每个任务都有一些估算，这会影响当前的冲刺。在冲刺期间，任务是在实际时间内完成的，并基于此燃尽图显示团队在交付客户价值方面的进展。客户从会议中获得了什么价值？此外，这样的任务可能与具体用户故事无关，因此，在产品燃尽图中将看不到任何进展。当您必须考虑未包含在复杂性（故事点）中的价值时，您如何决定下一个冲刺应采取多少用户故事？
向您的冲刺积压中添加这样的虚拟任务（没有增加价值的任务）也会影响您的速度。它看起来每个故事点的成本都比实际情况更高，因为会议时间将包括在实际工作中。
您想要向您的冲刺积压中添加什么类型的会议？SCRUM只需要少数会议——每日会议、计划会议、审查会议、回顾会议以及在较大的项目中的SCRUM of SCRUM。每日会议非常短，不必包含在计划中。计划会议、审查会议和回顾会议不必包含在冲刺中。SCRUM of SCRUM是特定的，它不影响整个团队——可以从参与成员的计划容量中减少。不需要更多的会议。最重要的是：完成任务所需的沟通是任务估算的一部分。
如果您需要其他会议，请简单地减少您的容量。如果客户、管理层或产品所有者抱怨容量太小，请简单地向他们解释这是由于非标准行政或官僚开销所致。
- Ladislav Mrnka
1
1+1。非常好的答案。具体来说：任务与产品积压无关。任务与Sprint积压有关，并且完成任务所需的沟通是任务估算的一部分。 - Sebastian
2
如果会议或其他非开发任务直接与实现冲刺\迭代\项目目标有关，则我没有问题将它们包含在冲刺待办事项\迭代计划中。这样做可以提高任务的可见性，确保它们得到完成。
- PeeGee
2
我认为，如果这些任务与某个功能（如培训）没有直接关联，那么你不应该将它们包括在产品待办列表中，而是要调整开发人员的可用时间，从而调整迭代的速度。尽管一周工作40小时，但你不能指望人们在项目上花费全部40个小时。
- Franco
2
在我的上一个项目中，我们将一些活动加入了我们的Scrum看板。它们不在产品待办事项清单中，但是我们在计划会议期间想出了它们。
我们包括的活动类型包括客户研讨会、发布活动等。
我们将它们放在我们的Scrum看板上的原因是为了让团队中的任何人都能看到其他人正在做什么，并且在某些情况下还可以将任务分配给没有处于另一个关键任务中的人。
我们包括的活动类型包括客户研讨会、发布活动等。
我们将它们放在我们的Scrum看板上的原因是为了让团队中的任何人都能看到其他人正在做什么，并且在某些情况下还可以将任务分配给没有处于另一个关键任务中的人。
- Albin Sunnanbo
2
典型的重复任务由估算/速度吸收。例如站立会议、普通开发者互动、暂停等等...
对于与产品构建无关的其他事件，我更喜欢从开发人员的可用性中删除那些时间，以获得正确的容量。
因此，我们可以计划的用户故事数量取决于它们的估算、团队速度和当然容量。
- user333306
1
如果您的需求清单中不包括人们需要做的事情，您将如何管理它们？
非开发项目需要时间，与开发和质量保证工作一样重要，以交付优质产品。
您可以选择使用单独的需求清单或在单独的项目计划中进行管理，但这样您就需要处理两个工作需求清单，排序和时间安排会成为问题。
我通常强制团队为非开发活动创建用户故事，例如“作为产品经理，我需要制定路线图”，或“作为产品经理，我需要设置技术研讨会以审查需求清单，以便开发团队了解功能”。
这真的取决于情况，但如果需求清单是捕获和管理工作的核心位置，为什么只用于开发和质量保证工作呢？
非开发项目需要时间，与开发和质量保证工作一样重要，以交付优质产品。
您可以选择使用单独的需求清单或在单独的项目计划中进行管理，但这样您就需要处理两个工作需求清单，排序和时间安排会成为问题。
我通常强制团队为非开发活动创建用户故事，例如“作为产品经理，我需要制定路线图”，或“作为产品经理，我需要设置技术研讨会以审查需求清单，以便开发团队了解功能”。
这真的取决于情况，但如果需求清单是捕获和管理工作的核心位置，为什么只用于开发和质量保证工作呢？
- chrish
1
在Scrum中，没有固定的公式来决定用户故事。在我的项目中，我们挑选并选择哪些工作项应该转换为故事。例如，像比较2-3个IDE开发工具这样的任务会放入待办事项列表中，因为它与开发直接相关。但是，我计划每个团队成员每天进行5小时的开发活动，以便他们花费其余时间参加培训、文档编写、知识交流、同行编程等。这对于我来说可以证明演示与冲刺速度之间的关系。
- mehtak
0
您可以在 Trello 看板中管理非开发任务。这些任务可能是研究活动或者获取数据以供开发使用。它们不属于 JIRA 或 Rally，因为它们不是开发任务，也没有故事点估算。
- Mandy
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接