Skip to main content

Can a developer be a member in two scrum teams?

Last post 08:31 pm April 29, 2014 by Abhishek Sen
12 replies
05:26 am April 29, 2014


We are running in a situation when several developers are allocated to work 60% from their time on Project A and 40% on Project B.

There are two Scrum teams, team A for project A and team B for project B. Which is the best way to handle this situation? Can a developer be a member in both Scrum teams?



05:53 am April 29, 2014

Hi Mercia,
I would recommend moving away from Project concept and adopting the Product Backlog. Once you break down your work into Product backlogs and prioritise your work it will pave the way of working as an ideal scrum team rather than team for project A and team for project B.


09:56 am April 29, 2014


I should clarify. There are two different products with different product backlogs. Project A means Product A and Project B means Product B.

Sorry for the unclear details.



10:31 am April 29, 2014

Mircea - Apologies for getting your name wrong in the earlier post

The Scrum Guide states

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product

Stress must be given to the words 'single source of requirements'.

I would suggest merging the two product backlogs and prioritize the work. This will help identify
1) the most important backlog items.
2) the items which have the necessary level of information to progress it to sprints.

Your scrum teams will then pick up the PBI and progress them to completion - irrespective of which 'project' the work belongs to.

11:00 am April 29, 2014

Hi Hims,

Thanks for answer. Not sure that merging the two backlogs is a solution. Scrum guide states that "The Product Backlog is an ordered list of everything that might be needed in the product". If we perform the merge then most of the stories from product backlog will apply only to one product, so will be elements that are not needed to complete a product but the another one.

Also, merging the backlog will decrease the transparency as the stories from one project will be a noise for the second project and otherwise.

There are several scrum teams working on Product A and several scrum teams working for Product B. Some of these teams are working only for Product A, other teams are working only for Product B.

Product A and Product B have different product owners and are driven by different departments from company. We are specialized in infrastructure so we will be involved in both projects but other people will be in only one project.



11:05 am April 29, 2014

A quote from Verheyen, Gunther (2013-11-04). Scrum – A Pocket Guide (Best Practice (Van Haren Publishing)), section 3.7.3: "For each product a Product Backlog exists with one Scrum Team or multiple Scrum Teams to create and sustain it".

It seems that merging two product backlogs is not a solution.



11:19 am April 29, 2014

Nevetheless team working on more than one product is not a violation of the Scrum Rules (the team can even work on several products at once), you should be aware of potential losses in productivity due to interruptions and switching focus.

You'd better keep the following ratio unchanged: One Product/One Product Owner/One Development Team.
If it's not possible (I don't believe though :)))) then go with the different formula: let the team focus on product 1 during several Sprints and then switch to product 2 several Sprints.

Working on several products at the same time is the worst scenario.

12:34 pm April 29, 2014


We cannot focus only one product for several sprints as there are dependencies with other teams that are working only on one product.

So we should keep in sync and develop for both products in the same time/sprint. The sprints are aligned for both products.



12:37 pm April 29, 2014

If the same team works for two products with different product backlogs then we will have problems with the meetings: planning and review.

12:49 pm April 29, 2014

If you can split your team into 2 and stil keep both of the smaller teams cross-functional and being able to produce potentially releasable products (Product 1 and Product 2) each Sprint then it would be fine. Otherwise you won't be able to avoid losing focus and inevitable interruptions.

I assume this is suboptimal somehow and the real answer to this issues is on the higher level (up to your team, you've mentioned dependencies).

12:58 pm April 29, 2014

This topic is covered in 'Scaling Scrum' -

Have a read and let us know if it helps.

04:54 pm April 29, 2014

> We cannot focus only one product for several sprints as there are dependencies
> with other teams that are working only on one product.

A variation on this theme is to alternate between products on a sprint-by-sprint basis. This can make it easier to integrate with other teams. You might also consider shortening your sprints (to half the usual length) so that a potentially releasable contribution can be made to both products in the same organizational sprint cycle.

As an aside, some organizations use this alternating model so a single team can provide support for both project and BAU work.

08:31 pm April 29, 2014


I actually have this situation currently. We have 4 scrum teams (although working from a common backlog). Due to the complexity of the different technologies involved, we share a couple of developers across 2 teams. In my experience it has worked out fine, as long as the developers involved are present when each of their teams make significant decisions, such as pulling in work from the backlog, poker planning etc. It creates some logistical problems, but other than that it should work. It’s important to get buy in from the people who are going to be on 2 (or more) teams, and schedule important team activities so that they can participate in these for both teams.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.