3

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?

4

I would add an additional option: allow your scrum teams to select whatever they want off the backlog.

You have given the scrum teams a prioritised overall backlog and they know what they are capable of delivering. If you allow the teams the complete freedom to take whatever stories they want to into their sprints then the overall process should deliver optimal results. This only gets complicated if the scrum teams hold separate sprint planning meetings simultaneously...

As a product owner, as always, you only need to intervene if the scrum teams are not taking your highest priority items into their sprints. If not, you need to establish why in dialogue with the scrum master(s) and together agree some action.

  • That's going to be a little bit of a scary sell to management, but on reflection, this seems like it's probably really the right way to go. – mattdm Feb 15 '12 at 20:06
  • Here's the sell: One of the agile principles is "the best architectures, requirements, and designs emerge from self-organizing teams." Your management need to trust your teams to be self-organizing - to take work from the backlog rather than have it assigned to them - otherwise they will be undermining the adoption of agile methodology. – Paul Harrap Feb 15 '12 at 20:52
  • This model is good ( and we use it at our company as well ) but as a PO/Scrum Master you have to monitor & balance the freedom given with a urge/tendency of teams to pick up only those stories which are comfortable(skilled) at or are intrigued by.If this keeps on bleeding might create pockets of knowledge restricted to particular teams. – the_reluctant_tester Apr 18 '12 at 0:07
0

First of all making your team functional you'r violating agile/SCRUM rule and you already described why it's bad.

Next, you could allow teams to pick US from common BL, but it could lead to situation where single team will pick up first N highest priority USs. It's possible that at the end of the sprint they won't deliver one of USs and you will miss something important. It's OK if you've got another sprint, but if it's release date ?

Everybody know the rule - don't compare teams velocity, but it means that we shouldn't compare teams estimates as well, so results of gathered estimation is useless.

My proposal will be to restrict single team to pick up top of the backlog or spread this risk manually. I'll suggest you to not involve all teams or teams representatives into estimation, they will give you aggregated estimates, you could prioritize common backlog and spread it across the teams.

Example: If you've got 2 scrum teams and prioritized common BL you could spread it in the next way:

US_1 -> team_1
US_2 -> team_2
US_3 -> team_1
US_4 -> team_2

Each team will estimate their own backlog and priorities will be along with overall.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.