We have a development team that works on multiple "products". We create a unified user-stories backlog, and effectively treat the multiple products as different feature areas of the same virtual big product. Each iteration ideally focuses on related user stories, so that doesn't, in practice, get too crazy — although there's often high-priority unrelated items which make the cut.
My organization is growing to the point where it's no longer sustainable for there to be just one scrum team. I'm thinking about how to make this work so that the user stories are divided in a way that is a) functional for the teams and b) keeps all work focused on the overall priorities of the organization.
We want to keep one overall backlog for the multiple teams; keeping our whole organization working on unified priorities is part of the point of this whole thing. (And I've seen council that this is the right way to go.)
One obvious division is functional responsibilities. Product A and B go to Team 1, while product B and C go to Team 2. I expect that that's how most people do it. The problem with this is that sometimes products B and C might just not be a priority at all. (Since we work to an academic schedule, that is often the case at certain times of the year.) In that case, we end up with Team 2 working on items from further down the backlog which don't really match the priorities of the organization as a whole, just because hey, that's what their job says to do. A possible solution is to make the teams fluid, with team members shifted from Team 2 to Team 1 when Team 1's products are the current priority.
Another approach is to have the first part of the sprint planning meeting involve both teams. There would be a group discussion about which user stories go where, and how much each team can commit to. The clear problem with this is that it's hard to scale — but I've heard of people doing it nonetheless. One solution is for each team to only send delegates to this part of the planning meeting. These delegates would have the responsibility of negotiating a reasonable selection of user stories for their team.
Which approach is best, and why?
In the model where the teams have different areas of responsibilities but the team composition changes each cycle, when are the reassignments made and whose responsibility should that be?
In the model where the planning meeting includes all team members from all teams, how does one make that work effectively? Consensus is very difficult when there's more than a few people involved!
In the model where the initial part of the planning meeting is attended by delegates, how much authority should those delegates have and what happens when their commitments have a mismatch with the team?
Is there a refinement of these ideas or a different model for multi-team scrum that I should be looking at?
