Forums

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

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Can a developer be a member in two scrum teams?
Last Post 29 Apr 2014 03:31 PM by Abhishek Sen. 12 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Mircea Cezar Preda
New Member
New Member
Posts:13
Mircea Cezar Preda

--
29 Apr 2014 12:26 AM
    Hi,

    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?

    Thanks,

    Mircea
    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    29 Apr 2014 12:53 AM
    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
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    29 Apr 2014 04:56 AM
    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
    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    29 Apr 2014 05:31 AM
    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.

    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    29 Apr 2014 06:00 AM
    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
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    29 Apr 2014 06:05 AM
    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
    Ilia Pavlichenko
    New Member
    New Member
    Posts:71
    Ilia Pavlichenko

    --
    29 Apr 2014 06:19 AM
    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.
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    29 Apr 2014 07:34 AM
    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
    Mircea Cezar Preda
    New Member
    New Member
    Posts:13
    Mircea Cezar Preda

    --
    29 Apr 2014 07:37 AM
    If the same team works for two products with different product backlogs then we will have problems with the meetings: planning and review.
    Ilia Pavlichenko
    New Member
    New Member
    Posts:71
    Ilia Pavlichenko

    --
    29 Apr 2014 07:49 AM
    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).
    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    29 Apr 2014 07:58 AM
    This topic is covered in 'Scaling Scrum' - http://www.capgemini.com/blog/cappi...ling-scrum

    Have a read and let us know if it helps.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1677
    Ian Mitchell

    --
    29 Apr 2014 11:54 AM
    > 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.
    Abhishek Sen
    New Member
    New Member
    Posts:2
    Abhishek Sen

    --
    29 Apr 2014 03:31 PM
    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
    You are not authorized to post a reply.


    Feedback