One Scrum team, with a shared product Backlog between three PO using TFS 2013

Question

We have a Scrum team, which concurrently working on 3 products, each of products has its own PO and Backlog. We decided to combine all Product Backlog, which main all three PO add he's Backlog Items, added to the same Product Backlog, and team member select PBI from this Backlog Item. I should say we have a Super PO(PO's of PO) who's get all Backlog Items from all other three PO and add to the shared Product Backlog. So, first of all, I want to know, does this approach is good and efficiency? If no, what approach we should Better choice?

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.

Thanks a lot

Answer 1

You can do this easily in TFS/VSTS by creating A Team that points at the root Area Path and then creating three Teams (one for each Product Owner) that point at the Product Area Paths under it.

/TeamProject <-- Your root team owns this and all sub areas. This is where your software team works /TeamPeoject/ProductA <-- Your ProductA team owns this area. The PO for ProductA works here and prioritises his backlog. He will see only his stuff and only his stuff in Sprints.

While this method will technically work in TFS/VSTS you should look to fixing the Process issues in your organization that result in this problem in the first place.

But you must consider

• How will your software team know which stuff to work on if they have three prioritised backlogs?
• What does multi-talking within a Sprint do to productivity?
• What would multiple DOD and other efforts to create multiple Done increments of software in a single sprint do to product quality?

This is a hard problem in your situation and there is no tool that can help you solve this business issue.

Answer 2

Well, first of when you change something, it is not that thing anymore.

In Scrum the team is 3-9 people who work on a backlog for a sprint of 2-6 week.

If you change any of these, it is not scrum anymore. You can call it agile, but it will be your custom agile process that no one has tested and no one knows how it will end up.

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.

I simply don't get what you gain by complicating everything. What is your gain by having stand ups with people talking about 3 different projects? What is the focus?

And you have 9 people max, but you have 4 owners them? :D that's funny.