tfs - 何时根据功能请求创建 PBI，以及在何处划分它们的界线？-6ren

tfs - 何时根据功能请求创建 PBI，以及在何处划分它们的界线？

转载作者：行者123 更新时间：2023-12-04 18:22:07

<分区>

我们公司正处于开始使用 Scrum(结合 TFS 2010 和 MS Scrum 模板)的过程中。由于我们都没有任何经验，因此仍有一些问题需要回答。

由于我们的产品经理和 Scrum Master 不是技术人员，这意味着我们开发人员将参与将功能请求拆分为小的产品待办列表项的 session 。我相信我们可以在我们的“计划扑克” session 上讨论这个功能。但这是如何计划的呢？假设我们在 sprint 进行到一半时收到了一个新功能请求。 (我们的 sprint 将按 80/20 计时。)我们是否应该在规划我们的 sprint 时也考虑到这一点，还是仅仅意味着我们在该 session 上花费的时间必须导致项目移回产品待办列表。
我们知道我们应该将一个功能分成尽可能多的 PBI(当然，这是有道理的)并且单个 PBI 不应超过一个 sprint 的长度。这也是有道理的。但是我们应该在哪里划界线呢？例如，我们的应用程序与多个 USB 设备通信。功能请求是我们应该与新设备通信。实现这是一个两部分的工作:
a) 将与设备的通信添加到我们的 USB 库中；
b) 为该设备添加 UI 支持
我们应该将其分成两个单独的 PBI，还是应该在这个 PBI 中创建多个任务？

旁注:添加 PBI 后，我们是否应该在开始实现时为每个 PBI 创建一个任务？据我在 TFS 中看到的，我们无法在 PBI 上设置剩余工作时间。所以我最初的想法是为每个 PBI 创建一个任务。但我知道有些同事会发现为只有一个任务的 PBI 创建任务“需要大量工作”。我们应该如何处理？