我们应该如何命名已在多个 sprint 中拆分的 PBI？

Question

在停止当前的 sprint 后，我​​们需要将很多项目移动到下一个 sprint。这提出了一些问题，我们作为新的 scrum 用户没有找到答案。

我们知道我们需要创建新的 PBI，并将标记为待办事项的任务移动到新创建的 PBI。 （以及 In Progress 任务会发生什么，应该如何移动它们？只是移动它们，或者关闭它们并为新的 sprint 创建一个新的？）

提出的讨论之一是我们应该如何命名我们的 PBI，因为管理层希望它对我们的客户来说足够清楚，他们可以阅读我们的产品待办事项和 Sprint 待办事项。

从开发人员的角度来看，PBI 诸如“研究功能 A”、“实施功能 A”、“波兰功能 A”，而我​​们的管理层认为 PBI 应该命名为“功能 A（第 1 部分）”、“功能 A（第 2 部分）”、“功能 A（第 3 部分 - 结束）”，因为他们和我们的客户都不了解我们的 PBI，他们想知道何时可以开始测试功能 A。我们的管理层基本上只想打印出 Sprint积压查询并将其传递给我们的客户，以显示已完成的工作。

第二个不太重要的问题是：我们应该如何正确使用区域路径？如果我们有一个特征 A，那么创建一个特征 A 区域路径并将其用作所有 PBI 和与之相关的任务的通用标识符对我们来说是有意义的。但是我们应该如何处理与多个特征（以及区域路径）相关的工作项？我们担心我们最终会得到很多区域路径，并且列表会变得混乱。我们无法删除区域路径，因为可能会为此提交错误，或者我们需要在稍后阶段将其拾取。另外，如果某个功能已经在应用程序的多个版本中实现了怎么办？

Answer 1

我们知道我们需要创建新的 PBI 并移动任务 标记为对新创建的 PBI 的待办事项。 （会发生什么 对于 In Progress 任务，应该如何移动它们？只需移动它们，或者 关闭它们并为新的 sprint 创建一个新的？）

您无需为每个 sprint 创建新的 PBI！ PBI 一直在进行，直到其所有子任务完成。它的迭代可能会前进到下一个 sprint（例如，“Release 1\Sprint 1 > Release 1\Sprint 2”或者只是停留在上层（“Release 1”）。任务不会转移到另一个 PBI，但可以进入下一个 sprint。

这将解决命名问题，因为 PBI 不会获得“part X”后缀。 PBI 的一个可能名称是“功能 A - 基础设施”或“功能 A - UI”。所以它的子任务可以命名为“功能A-基础设施-设计”、“功能A-基础设施-实现”和“功能A-UI-设计”等等。

第二个不太重要的问题是：我们应该如何正确使用 区域路径？

如果Iteration是一个时序的时间点，那么Area就用来表示产品的一个逻辑模块。例如：

|-Server
| |--Database
| |--Web Services
|
|-Client
| |--UI
| |--Navigation
|
|-Configuration
|
|-Documentation
|
|-Installation
| |---Client
| |---Plugins
|

不要过度使用区域定义。列表应该简洁易懂。

如果某个功能在应用程序的多个版本中实现了怎么办？

创建另一个 PBI 并为其分配相同的区域路径但不同的迭代路径。