Multi-project multi-team Scrum

Question

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?

Answer 1

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.

Answer 2

One word of advice on story points---I generally do not like to share the raw points with outside parties. Team A and Team B (especially if they are not co-located and in conversation with one another) are going to have their own relative points and should be allowed to gauge their own baseline and level of effort for each user story. I've seen far too many discussions between stakeholders and the product owner over why team A is able to have a velocity of 50 per sprint while team B has a velocity of 25. I'm all for transparency, but you have to protect your team members from that kind of discussion. If you have to report anything externally, I'd come up with a translated tee-shirt size from the points like "1-3 (Small) 5-13 (Medium) 20-40(Large) 100+(XL)." This is especially important when you have strong, opinionated stakeholders who are not familiar with Scrum and the idea of story points and relative estimation. Your best bet is to just to let them see the backlog's priorities, the general release plan, and maybe a backlog burn-down chart that shows no points, only the trend line with dates. Those points are there first and foremost to elicit discussion among the team members about the level of effort. After that takes place, it may help you as a product owner or scrum master to plan better. It was never meant to be an objective score for your stakeholders to judge your teams efficacy or hard work. Making it so will discourage them from being honest.