Back to Forum

Scrum Teams with Different Skillsets Drawing from Single Backlog

Last post 03:33 pm March 20, 2019 by Marco Glorie
3 replies
Chandler Berty
02:49 pm March 15, 2019
  1. We have one product backlog composed of items split across: 
    1. Front of store retail activities: view inventory in X fashion in app
    2. Back of store / logistics activities: enable real-time inventory views

       
  2. There will be different scrum teams who are developing against this single backlog.
    1. Some with expertise in customer facing UI (front of store)
    2. Some with expertise in ERP (back of store)

My questions: 

  1. Does the way this backlog is structured make sense? The front-of-store and back-of-store activities are closely coupled, so splitting them apart creates two backlogs which are heavily reliant on each other. 

     
  2. Product Owner would prioritize the backlog based on whatever they see as highest value for a given sprint.  Then the scrum teams would look at the work to determine which team should take which items? 

I think one response may be, "Author the stories in a way which has development efforts for both teams (front-of-store and back-of-store) in the same user story."  

Ian Mitchell
08:54 pm March 15, 2019

There will be different scrum teams who are developing against this single backlog.

  1. Some with expertise in customer facing UI (front of store)
  2. Some with expertise in ERP (back of store)

Why? Why would this structuring of teams make sense, if they then struggle to develop features without impediment or dependency?

Eugene M
10:36 am March 18, 2019

What you have there, Chandler, is a very good example of component teams (front-end + back-end). Would you not be better of with feature teams that pick up work from a single backlog? Why split the single backlog into 2 or 3 ones, and have component teams step on each others' toes? 

Marco Glorie
03:33 pm March 20, 2019

I agree with Eugene. Take a look at the LeSS methodology. Organizational wise it might be better to have multidisciplinary product feature teams. Although this is in practice not always possible, so component teams then might be a suboptimal solution.

Please be aware that in that case, from prioritizing on higher level and managing dependencies work gets harder on the product owner mainly and also the scrum masters

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

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.