One team that's developing for multiple products. Do I create a separate product/sprints for each product, or combine all into one?

How many people will there by in Site B? Enough for a fully-capable, independent Scrum Team?

My opinion would be yes straight off because you have 2 products.

Your resource planning of 70%-30% is not bad either I have done that many times. You just need to take that into account when you do sprint planning for both sites.

This is where I fall out with many scrum masters but I have a lot of background doing this very thing it can work and  does work.

Do you have a Product Owner who can represent any of this work at all? Is it you? If each site constitutes a separate product, then you should expect to manage two distinct Product Backlogs.

Other things to consider:

• Why would individual team members observe something like a 70%/30% split, rather than the team itself? Where would the shared focus and teamwork be?
• If a team drew work from two different Product Backlogs in the same Sprint, would it then be possible to frame a coherent Sprint Goal as per the Scrum Guide?

Alvin in this instance and because I have been faced with a similar issue I have used traditional Scrum for one team (70%) and a Kanban approach with the other team (30%). If you don’t get resource and capacity planning google it. You again just to make sure you plan the scrum team that is sprinting work accordingly to 70% that way you don’t over commit that team.

The Kanban team just used WIP and cycle times we never sprinted with that team although we could had we wanted to. We released product from both teams one time a month. The Scrum team released every 2 sprints if they had something useable and the Kanban team released whatever they had in the ready to release column. It worked pretty well most of the time.

If you have two products, you must have two teams, each one with your sprints and product backlog.

Remeber: The sprint's output is 'a releasable increment' (about ONE product).

Remeber 2: Scrum master: one or more teams/products. PO: one or more teams/products. Development Team: one PO, one Scrum master and one (JUST one) product backlog/product.

Everton,

That is the desired way that does not always work out that way especially in small orgs.

The term “must have” is not accurate.

He could do as I stated above and do resource planning with his nine members to work between the 2 products.

Or he could split his nine-member team into 2 new teams. He’d probably create some resource dependency, but he may have dependencies already.

Do you really have two products? I mean what even is a "product?"

If you take the LeSS philosophy, you would probably say that they're two applications that are part of a single product (i.e. organizational capability,) but that's talking idealistically, and most organizations are going to pigeon hole you anyway, so better consideration: what really matters here is the team, and the "best" solution depends.

For example, if your company produces an iOS and an Android app that is nearly identical, does it really make sense to have two completely different teams, or is it better to have the teams collaborate where they can (on things like UX, maintaining consistency, etc) and specialize where they need to specialize (iOS developers v Android developers.) Again, it depends.

How strong are agile software development principles and Scrum practices within your 9 person team?

If their agile practices are strong, hey, it's easier for 4 people to work together than 9.

Are you able to divide the team in a way that both new teams will be cross-functional?

If not, you will need to balance capacity across the two teams as resources are shared while each team develops the necessary skill set to be truly cross functional.

What is the risk of making half of your team "application maintainers and bug squashers" while another team gets the glory of working on something new? Will you lose people if you divide up the work that way?

Maintaining software is important, but ambitious developers do not like just being bug squashers and code maintainers. There might be some animosity if you divide up the team and some folks get to work on the cool new thing while others get left behind.

Are the two sites going to be completely decoupled or do they have any shared dependencies?

You're going to increase complexity by treating these sites as two products and dividing up the team if there's any dependencies between these two sites in any way (i.e. shared services, database, etc.) Now the teams will have to go out of their way to make sure they communicate any possible impacts to the other team instead of just working together as a single team.

Ultimately you have a few options:

1. Two products, two backlogs, two teams, and borrow each other's expertise until both teams are fully cross-functional and no longer need to borrow from the other team.
   
    
2. Single "product," single backlog, single team -- you continue prioritizing the work as you would if they were a single product (most tools will let you "tag" or "label" stories to identify which site they belong to...in the mobile example above you could use the labels "iOS" and "Android" to discern between the two.)
   
    
3. Single "product," single backlog, two teams (i.e. Nexus it.) -- you continue to prioritize the work as you would if they were a single product, but the teams could take on the work for either product depending on what makes the most sense per sprint. -- quite frankly, since your team is only 9 people, this is adding more process than is necessary, and I wouldn't do it.

I would NOT pull from two product backlog for a single team...that's SUPER messy and will make transparency for the team's work hard to discern.

A final thought: Rather than deciding for the team, you could ask your team what they'd like to do and see what they think would be most comfortable and effective for them.

Good post Kevin.

Hi Filip,

I might not have enough for a separate team. I have 2 frontend developers that take turns working on Site A and B.

Thanks everyone for the feedback. Gonna think harder on this.

I've wrote a blog about the subject Multiple Products Scrum teams how to deal with that?

@Alvin At least the concensus in the group of the NLSCRUM community was, that a Scrum team should have ONE backlog and just ONE plan for the Sprint. Which may contain items for multiple products! 

hi @Alvin

I have wrote a blog about the subject https://xebia.com/blog/multiple-products-scrum-teams-how-do-you-deal-with-that/ 

and to more specifically answer your question, in the meetup of the NLSCRUM community consensus was there that one Scrum team has One backlog, and One plan for the Sprint. The backlog may contain work for multiple products which are within your team. This situation has some advantages and disadvantages, read the blog!