2 teams (A and B) in different geo locations are developing Project P. Both of the teams are also developing few other smaller projects: A has projects PA1 and PA2. B has PB1 and PB2. P is the only one common to the 2 teams.The Scrum design today: Each team has a PO, and they decide on the priorities together.One common Backlog that contains stories from project P and from PA1 and PA2. PB1 and PB2 are done off-scrum.Each team has its own sprint and SM. Team A picks stories from the backlog that are related to projects P, PA1 and PA2. Team B takes stories only related to P.The problem:I want to manage PB1 and PB2 in Scrum as well.Possible solutions:Add PB1 and PB2 to the same Backlog? - will complicate the backlog even more than now.Separate to 3 backlogs (P, PA1-2, PB1-2)? - There is a rule of one backlog per team... Should we break it? And is it even supported in TFS?Any idea how to solve the problem?
Multi-project multi-team Scrum
agile;scrum;product backlog
I'm currently 2/3rd of the way through Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise and I would highly recommend that book as it covers a lot of the topics issues involved in scaling out agile process to more than one team and maintaining backlogs for enterprise-level products (i.e. those that might span years)Although I haven't encountered your specific situation so I can't really say how well my advice would work in practice, based on my own experience with Agile, combined with external reading, this is what I would suggest:Maintain separate backlogs for each product. So you would have five backlogs: P, A1, A2, B1, B2. This way each backlog clearly indicates where you are in that product's development and what lays ahead for that product.When you have too many stories in a backlog, you reduce overall agility as there's more things for you to manage.  Having 5 different products in one backlog won't be very productive.  Especially if you have more than one product owner.  How much moving around would you have to do if you had a single backlog and all of a sudden your CTO comes to you and says, A2 is your highest priority, put everything else on hold? Leave product backlog at a somewhat high-level (i.e. don't break stuff down to 1-3pt). Having only larger items will again reduce the number of stories and the teams need to deal with and will make it much easier to prioritize work.Create 2 team backlogs: A and B. Based on business needs and priorities you should able to pull stories from P, A1, and A2 and transfer those into A.  And P, B1 and B2 would get transferred into B.Ideally you would only have several iterations worth of stories in the team backlogs. This way as business needs and priorities shift, you'll be able to adjust the volume of stories that you pull from each of the product backlogs. These team backlogs would take product stories and possibly break them down into finer chunks with more details defined.  But you'd only fill in details when the team is ready to actually do the work.The positive thing is that having separate product backlogs means that you'll have 5 velocities and you will be able to predict exactly when each feature for those products will be delivered.The challenge will be to standardize the point scale across the 5 projects and 2 teams because if different products/teams use different point scale, your velocity will be worthless.  The book I mentioned above talks about some of the ways for this standardization.  Basically, you want to start with same base weight (e.g. 1pt ~ 1 day of work).  Also having scrum of scrums meetings (possibly with technical leads) will help with higher level planning, equalizing the point scale and coordination of work between the teams.