何时从功能请求创建PBI以及在何处绘制分割它们？

Question

我们正在开始在公司中使用Scrum（与TFS 2010和MS Scrum模板结合使用）。由于我们都没有任何经验，因此仍有一些问题需要解答。

1. 由于我们的产品经理和Scrum Master是非技术人员，这意味着我们，开发人员将成为在小型产品Backlog项目中拆分功能请求的会议的一部分。我相信我们可以在我们的“策划扑克”会议上讨论这个功能。但这是如何规划的呢？假设我们在sprint中间收到一个新的功能请求。 （我们的sprint将是80/20定时。）我们是否应该在规划我们的冲刺时考虑到这一点，或者它只是意味着我们在该会议上花费的时间必须导致项目移回产品Backlog。

2. 我们知道我们应该将功能分成尽可能多的PBI（当然，这是有意义的）并且单个PBI不应超过一个冲刺的长度。这也是有道理的。但是我们应该在哪里画线？例如，我们的应用程序与多个USB设备通信。功能请求是我们应该与新设备通信。实现这个是一个两部分的工作：

   a）将与设备的通信添加到USB库中;
   b）为此设备添加UI支持

   我们是否应将其拆分为两个独立的PBI，或者我们应该创建多个任务的PBI？

侧面说明：当添加PBI时，我们应该在开始实施时为每个PBI创建一个任务吗？就我在TFS中看到的，我们无法在PBI上设置剩余工时。所以我最初的想法是为每个PBI创建一个任务。但我知道有些同事会发现为一个只有一个任务的PBI创建任务“需要做很多工作”。我们该如何处理？

Answer 1

1. 在Scrum中，将功能分解为足够小的用户故事是PO的责任。话虽如此，PO在分裂它们时从团队（或其他任何人）获得帮助并没有错。由于团队对每个故事的复杂性的输入，规划扑克会议可能是微调分割的好地方，但是PO应该具有如何预先分割故事的感觉。
2. 计划会议应该大致半天。绝对不是每个冲刺的重要部分。无论如何，冲刺中的剩余时间（例如90-5 = 85，在两周的冲刺中）应该是团队必须填写故事任务的时间量。当然，无论在sprint中剩下多少时间，团队不能承诺的任何故事都应该返回到产品backlog;它们不会在这个冲刺中完成。
3. 故事应该大小适当，即可以在一个sprint中完成。就个人而言，我更喜欢调整故事大小，以便团队在一个冲刺中完成一些故事。一个好的经验法则（但不是硬性规则）是当你达到团队可以在3-5天内释放它们时停止分裂你的故事。
4. 虽然您没有要求如何拆分您的功能，并按照核心功能，准入障碍，关键差异化因素和精彩 - 分开它们到富人即可。
5. 关于将故事分解为任务：每个故事至少应该有一个任务。故事定义需要完成的;任务定义如何。您应该在系统的每个参与组件中至少有一个任务，以及 **完成定义中每个可操作项的一个任务。如果你只有一个任务，那么你可能没有完成的定义，或者你的故事是定义实现，而不是功能。

关于TFS - TFS不会改变上述任何一项，但它确实支持我建议的所有内容。

Answer 2

是的，如果您在PBI下创建任务，即使它只有一项任务，也会更好，因为PBI用于监控产品进度，它在估算中使用了故事点（相对大小），但该任务用于监控工作进度，它估计使用了几个小时，因此每个工作项目都有不同的用途。

Answer 3

1）将故事分开的时间将反映在你的团队的速度中，所以你不应该做任何事情来计划它。如果你花费说，你的故事计划/分裂的一半冲刺每次迭代完成5个故事，那么你的计划就会反映出来。通过回顾展的使用，您可以看到花费更少的时间进行故事分割将增加您的速度，即每次迭代8个故事。请注意花费更少时间分割故事的副作用，这样你就能看到硬币的两面。

2）不知道应用程序，我会说将这一点分开的一种方法是

• 插入新USB设备时提醒用户（这可能会显示默认图标）
• 警报用户连接iPhone时（此设备周围有更多细节，可能还有不同的图标/图像）
• 安装Android时提醒用户（同上）
• 警报用户...（每个支持的设备可能只有一个）

绝对尽量避免在“前端”和“后端”等技术行之间进行拆分。由于我们的技术性质，它起初感觉不错，但演示并没有真正产生同样的影响，而您的PO和Scrum Master实际上并没有真正的进步衡量标准。

3）任务创建是您的团队需要弄清楚的事情。如果你正在运行2周的迭代并且团队没有找到有用的任务细分，那么我会说不要这样做。如果团队觉得它有助于他们分解创建故事所需的工作，那么，无论如何都要这样做。为了创造任务而创建的任务并没有使IMO充分理解。

希望有所帮助！

布兰登