一个 Scrum 团队，在三个使用 TFS 2013 的 PO 之间共享产品 Backlog
One Scrum team, with a shared product Backlog between three PO using TFS 2013
我们有一个 Scrum 团队，同时在 3 个产品上工作，每个产品都有自己的 PO 和 Backlog。我们决定合并所有产品待办列表，主要是所有三个 PO 添加他的待办事项列表，添加到相同的产品待办事项列表，以及团队成员 select 来自此待办事项列表的 PBI。我应该说我们有一个超级 PO（PO 的 PO），他从所有其他三个 PO 获取所有 Backlog 项目并添加到共享的 Product Backlog。
那么，首先，我想知道，这种做法好不好，效率高吗？如果不是，我们应该选择什么方法更好？
And We use TFS as a Scrum life cycle management, but we don't sure TFS can do this approach-one Shared Backlog Item for different kinds of Backlog Items from different context and different PO.
非常感谢
您可以在 TFS/VSTS 中轻松地做到这一点，方法是创建一个指向根区域路径的团队，然后创建三个指向其下的产品区域路径的团队（每个产品负责人一个）。
/TeamProject <-- 您的根团队拥有此区域和所有子区域。这是您的软件团队工作的地方
/TeamPeoject/ProductA <-- 您的 ProductA 团队拥有此区域。 ProductA 的 PO 在这里工作并优先处理他的积压工作。他只会看到他的东西，并且只会看到他在 Sprint 中的东西。
虽然此方法在技术上适用于 TFS/VSTS，但您应该首先解决组织中导致此问题的流程问题。
但你必须考虑
- 如果您的软件团队有三个优先级待办事项，他们将如何知道要处理哪些内容？
- Sprint 中的多方对话对生产力有何影响？
- 多个 DOD 和其他在单个冲刺中创建软件的多个完成增量的工作会对产品质量产生什么影响？
在您的情况下这是一个难题，没有工具可以帮助您解决此业务问题。
嗯，首先当你改变一些东西时，它就不再是那个东西了。
In Scrum the team is 3-9 people who work on a backlog for a sprint of 2-6 week.
如果你改变其中任何一个，它就不再是 Scrum。您可以将其称为敏捷，但它将是您定制的敏捷过程，没有人测试过，也没有人知道它会如何结束。
If you have 3 projects and you want to do it concurrently, make 3 teams that work concurrently.
If you don't have enough people to do that, use other methodologies.
我根本不明白使一切复杂化会得到什么。与谈论 3 个不同项目的人站起来有什么收获？重点是什么？
你最多有 9 个人，但是你有 4 个所有者 他们？ :D 这很有趣。
我们有一个 Scrum 团队，同时在 3 个产品上工作，每个产品都有自己的 PO 和 Backlog。我们决定合并所有产品待办列表，主要是所有三个 PO 添加他的待办事项列表，添加到相同的产品待办事项列表，以及团队成员 select 来自此待办事项列表的 PBI。我应该说我们有一个超级 PO（PO 的 PO），他从所有其他三个 PO 获取所有 Backlog 项目并添加到共享的 Product Backlog。 那么，首先，我想知道，这种做法好不好，效率高吗？如果不是，我们应该选择什么方法更好？
And We use TFS as a Scrum life cycle management, but we don't sure TFS can do this approach-one Shared Backlog Item for different kinds of Backlog Items from different context and different PO.
非常感谢
您可以在 TFS/VSTS 中轻松地做到这一点，方法是创建一个指向根区域路径的团队，然后创建三个指向其下的产品区域路径的团队（每个产品负责人一个）。
/TeamProject <-- 您的根团队拥有此区域和所有子区域。这是您的软件团队工作的地方 /TeamPeoject/ProductA <-- 您的 ProductA 团队拥有此区域。 ProductA 的 PO 在这里工作并优先处理他的积压工作。他只会看到他的东西，并且只会看到他在 Sprint 中的东西。
虽然此方法在技术上适用于 TFS/VSTS，但您应该首先解决组织中导致此问题的流程问题。
但你必须考虑
- 如果您的软件团队有三个优先级待办事项，他们将如何知道要处理哪些内容？
- Sprint 中的多方对话对生产力有何影响？
- 多个 DOD 和其他在单个冲刺中创建软件的多个完成增量的工作会对产品质量产生什么影响？
在您的情况下这是一个难题，没有工具可以帮助您解决此业务问题。
嗯，首先当你改变一些东西时，它就不再是那个东西了。
In Scrum the team is 3-9 people who work on a backlog for a sprint of 2-6 week.
如果你改变其中任何一个，它就不再是 Scrum。您可以将其称为敏捷，但它将是您定制的敏捷过程，没有人测试过，也没有人知道它会如何结束。
If you have 3 projects and you want to do it concurrently, make 3 teams that work concurrently.
If you don't have enough people to do that, use other methodologies.
我根本不明白使一切复杂化会得到什么。与谈论 3 个不同项目的人站起来有什么收获？重点是什么？
你最多有 9 个人，但是你有 4 个所有者 他们？ :D 这很有趣。