-2

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

EJoshuaS - Stand with Ukraine
  • 11,977
  • 56
  • 49
  • 78
Masoud Bahrami
  • 111
  • 1
  • 12
  • As soon as you say "we have one scrum team working on three products each with it's own PO" I know that you are in fact not doing Scrum. One Scrum Team works from on Product Backlog that is owned by one Product Owner. See: http://scrumguides.org – MrHinsh - Martin Hinshelwood Jan 02 '17 at 10:52
  • @MrHinsh I should say that, We have one team which in an sprint, the team works with one PO, but the important point is that the forenamed PO, gets PBIs from 3 other PO, each of them for one specific Product and Context, So the Product Backlog Items composites of PBIs from 3 different PBI – Masoud Bahrami Jan 02 '17 at 11:17
  • 1
    Sounds like my answer below will allow you to have three seperate Product Backlogs managed by each PO and a ln UberMaster Backlog managed by your UberProduct Owner that sees all... – MrHinsh - Martin Hinshelwood Jan 02 '17 at 19:03

2 Answers2

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.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
0

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.

Community
  • 1
  • 1
Ashkan S
  • 10,464
  • 6
  • 51
  • 80