Can a developer be a member in two scrum teams?

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.

Regards,
Hims

Hi,

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.

Thanks,

Mircea

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.

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.

Thanks,

Mircea

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.

Thanks,

Mircea

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.

Hi,

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.

Thanks,

Mircea

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

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).

This topic is covered in 'Scaling Scrum' - http://www.capgemini.com/blog/capping-it-off/2012/05/scaling-scrum

Have a read and let us know if it helps.

> 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.

Hi,

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.

Regards,
Abhishek