Evening all.

We currently have two feature teams, one Web one mobile. They have their own backlogs. Each have their own product manager and scrum master. Team size is 11 including scrum and product role per team.

We have an increasing demand for delivery outside of the product backlog from other projects. Some will touch Web, some will touch mobile and some will touch both.

We've proposed a 3rd team, who will be capable of working on Web and Mobile delivery from demand outside the existing backlog. In times of slack they will help the existing feature teams with their backlog.

However one lead is stating the CI/CD overhead will be too much and instead of creating a 3rd team, we should bolster the existing team sizes, which is against textbook.

I'm personally against this as I believe the existing product backlogs will also be pernially pushed back because the external demand will be of a higher priority.

Thoughts on how to proceed?

  • 1
    How many products are there - one product with one Web component and one Mobile component? Or two separate products, one for Web and one for Mobile? If there will be a third team, can the work clearly split up between the teams component-wise or product-wise?
    – Doc Brown
    Jun 13, 2017 at 21:34

3 Answers 3


CI/CD overhead will be too much.

It will be a lot. The overhead of absorbing new team members would be even more and much more difficult to track. Not only are you going against book by adding team members late, you're already over team size with 11 people on a team.

The pizza rule says no more on a team then two pizzas can feed. My rule is if turning around in your chair and talking to your team feels like public speaking it's to big. If talking to your team actually requires dragging everyone into a conference room, you're only team on paper.

With teams that size (11, sheesh) it would not only be a good idea to form a 3rd team it would be a good idea to pull two experienced developers from each of the two existing teams to form the third team with 4 other brand new developers.

This means the new teams will be 9, 9, and 10 making the new team the biggest which is by the book. Teams are meant to shrink not grow.

When forced to absorb new team members encourage them to pair junior developers with senior developers. Don't do hard assignments but allow for it. This keeps the getting-up-to-speed communication from overwhelming the team. Even with this it will slow the team down.

They might balk at this plan because it clearly shows how much this will impact productivity of the existing teams but that's precisely why I favor it. This makes the impact of this move clear. If they aren't willing to slow you down this much now to increase capacity months down the road they should stop messing with you.

If they do leave you alone then try this: Don't obsess on re-prioritizing work that has been de-prioritized. You wont get any credit for it. Express the risk of postponing it and move on. Some work needs to be done no matter what. Do it only so long as you don't mind not getting credit.

  • All sensible ideas. Particularly using resources from the existing teams. Jun 14, 2017 at 7:09

I think there may be other problems with a third team that is working on both products:

  • Who reviews the code changes? Members of the third team or members of the dedicated product team?
  • Who makes design decisions for each product?

Why aren't these other features just prioritized on the existing backlogs? I think the right move is to keep two teams and either highly prioritize these "other" features on the backlog or create a dedicated bucket of story points each sprint to work on these "other" features. If a feature touches both products and demands work from both teams, then employ cross-team stories.

  • Hi Samuel. Let's add another dimension to the mix. Outside of what I have described above there are 4 projects with their own feature teams working on the same code across Web and Mobile. The code merging will have to be reviewed as you rightly state. The product manager question is interesting as you can question on whether there is a 3rd product manager on the feature team or whether the existing product managers shape this work. I believe this is easy to solve, unlike the development challenge. Jun 14, 2017 at 7:27

It smells like a political historical thing you have two PMs (=POs?) in the first place. You should of course have one with a single backlog, there is only one product with multi-channel access, right?

You have 22 developers and yet, "you are not going fast enough" so you are looking at ways to scale up.

Something is wrong here. You'd better have a mighty big product to account for this situation.

Supposing you do, it would seem more appropriate to go back to one PO and one backlog and definitely not more than one SM. Then you could have 4 or 5 development teams and have a senior dev co-ordinate the teams, take care of inter-team issues. Each team would have their own planning sessions with the same SM and PO.

But given the way things are organized now, I suspect this kind of change will not be feasible in your organization.

  • Mobile application differs from the Web applications. We use the same vendor product for both, but one product is far more complex than the other. However they do share the same middleware and back end infrastructure. There could not be a single owner for the products. There are two different backlogs. Jun 14, 2017 at 7:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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