Tfs 何时创建PBI'；从一个功能请求中得到了什么？在哪里划分它们？

我们正在公司开始使用Scrum（结合TFS 2010和MS Scrum模板）。因为我们都没有经验，所以还有一些问题需要回答

由于我们的产品经理和Scrum主管是非技术人员，这意味着我们，开发人员将参加会议，将功能请求分解为小的产品待办事项。我相信我们可以在“规划扑克”会议上讨论该功能。但这是如何计划的呢？假设我们在短跑中间得到一个新的特征请求。（我们的冲刺时间将是80/20。）我们在规划冲刺时是否也要考虑到这一点，或者这仅仅意味着我们在会议上花费的时间必须导致项目移回到产品积压中

我们知道我们应该将一个特性拆分为尽可能多的PBI（当然，这是有道理的），单个PBI不应该超过一个sprint的长度。这也是有道理的。但我们应该在哪里划定界限呢？例如，我们的应用程序与几个USB设备通信。功能要求是我们应该与新设备通信。实施这项工作分为两部分：

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

我们应该将其拆分为两个单独的PBI，还是这是一个我们应该创建多个任务的PBI

---

附带说明：当添加了一个PBI时，我们应该在开始实现它时为每个PBI创建一个任务吗？据我所知，在TFS中，我们无法在PBI上设置剩余工作时间。所以我最初的想法是为每个PBI创建一个任务。但是我知道一些同事会发现为一个只有一个任务的PBI创建一个任务“工作量很大”。我们应该如何处理这个问题？

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

1）划分故事所需的时间将反映在您团队的速度上，因此您不必做任何事情来计划。如果你花了一半的时间在故事规划/分割上，每次迭代完成5个故事，那么你的计划就会反映出这一点。通过使用回顾，你可以看到花更少的时间在故事分割上会提高你的速度，比如说，每迭代8个故事。不过，要注意花更少的时间来分享故事的副作用，这样你才能看到事情的两面

2） 由于不知道应用程序，我想说，将其拆分的一种方法是

• 插入新USB设备时提醒用户（这可能会显示默认图标）
• 连接iPhone时提醒用户（这有更多关于设备的细节，可能还有不同的图标/图像）
• 连接Android时提醒用户（同上）
• 提醒用户。。。（每个受支持的设备可能有一个）

一定要避免在“前端”和“后端”等技术领域出现分歧。由于我们的技术特性，一开始感觉不错，但演示并没有真正产生相同的影响，您的PO和Scrum大师也不会真正有那么好的进度衡量标准

3） 任务创建是您的团队需要解决的问题。如果您正在运行2周的迭代，而团队没有发现任务分解有用，那么我会说不要这样做。如果团队觉得这有助于他们分解创建故事所需的工作，那么，无论如何，一定要这样做。为了创建任务而创建任务在我看来没有多大意义

希望有帮助

布兰登

在Scrum中，PO的责任是将特性分解成足够小的用户故事。也就是说，PO从团队（或任何其他人）那里得到帮助来拆分他们并没有什么错。由于团队对每个故事的复杂性的投入，规划扑克会议可能是微调分割的好地方，但是PO应该知道如何事先分割故事

计划会议大约需要半天的时间。绝对不是每次冲刺的重要部分。尽管如此，冲刺中的剩余时间（例如，在两周的冲刺中，90-5=85）应该是团队完成故事任务所需的时间量。当然，无论sprint还剩多少时间，团队无法提交的任何故事都应该返回到产品待办事项列表中；他们不会在本次冲刺中完成

故事的大小应适当，即可以在一次冲刺中完成。就我个人而言，我更喜欢调整故事的大小，这样团队就可以在一次冲刺中完成一些故事。一个很好的经验法则（但无论如何都不是硬性法则）是当你达到团队可以在3-5天内发布你的故事的程度时，停止分裂你的故事

虽然你没有问如何划分你的功能，并按照核心能力、进入壁垒、关键优势、和好东西来划分它们

关于将故事分解为任务：每个故事至少有一个任务。故事定义了需要做什么；任务定义了如何执行。在**done的定义中，每个参与系统的组件可能至少有一个任务，每个可操作项也应该有一个任务。如果您只有一个任务，那么您可能没有“完成”的定义，或者您的故事正在定义实现