Scrum Backlog addition

The Scrum Guide suggests that there is a single Product Backlog per product, owned by a single Product Owner.  Each Scrum Team has a single Product Owner, single Scrum Master and single Development Team.  The scenario you describe doesn't follow those guidelines so there isn't a Scrum answer for your question.  In reality you are doing Scrum-like activities.  

Given you aren't really using Scrum, my suggestion is to ask the teams how they feel it would be best to handle these scenarios.  Try something, inspect it and adapt accordingly.  I would use your entire post as a way to pose the question to the team.  And make sure that when you address the team, you are addressing the development team as well as product owners and scrum masters. 

BTW, even if you were using Scrum the above would still be my answer.  Don't try to make the right decision for them.  Let them organize their work in a manner that is efficient for them.  

The scenario doesn't contradict the Scrum Guide; as I stated, there are three products, and at least for the first two bullet points it was implied that there is only one PO and one SM. As a Product Owner, I can manage and be responsible for three individual Product Backlogs while using the same SM and DT. So the the activities are pure Scrum and not Scrum-like.

I understand your point and, of course, I would not decide this by myself and it would be a joint agreement with the rest of the team. I was just curious if there is an official approach to this or similar situations. 

I'm going to have to agree with Daniel Wilhite - you won't find a Scrum answer for this. Scrum is designed for a team supporting a single product with the work captured in a single Product Backlog. It also requires focus and commitment, and the situation that you describe has a team split three ways. That doesn't mean that you can't learn lessons or take practices and techniques from Scrum to solve your problem, I wouldn't call what you do Scrum.

My first recommendation would be to work with the team to figure out how they can organize the work and themselves to handle this case.

However, if the team was unsure or needed further guidance, my recommendation would be to maintain three separate Product Backlogs, one for each product. The team can select the work appropriately from each one and each iteration would result in modifications to one or more of the products. The team can use the same sizing and estimation methods for all of them. You would have one planning and one review for each iteration, where you would plan the work and then review the work across all three products.

Can the DT select and put in their Sprint Backlog items from different Product Backlogs?

If they did so, would the set of Product Backlog items they chose to meet a Sprint Goal -- and their plan for achieving it -- still be clear?

@Ian - yes. Me as a PO only expressed my desire to have the items from Product Backlog B or C done and clarified the actual items. The DT alone took the decision to include them in the Sprint along with items from Product Backlog A.

It appears from your comments that what your organization is doing works for them.  Is there a specific problem you are trying to address?  If not, I suggest that you keep doing what you are doing.  Maybe we are all missing something.  Can you provide some more information to clarify the user story we are working on?   <Sorry, could not help myself>.  :) But seriously, what problem are you trying to address?  Or is this just for your own knowledge? Either is fine but we may give different advice if you have a specific problem. 

And I actually enjoy these kind of conversations.  I learn from them every time.

It's a 50/50 mixture between a real scenario and knowledge.

Product A = the Webshop and Product B = Digital Asset Management system

Understandably, for the Webshop there is continuous improvement and changes, be they either cosmetic or functional. However, for the DAM system, nowadays there is probably one new section/filter to be added every quarter. As I initially stated there is only one DT.

Today the DT manages its own work by choosing to add in Webshop Sprint an item from the DAM system and there should be nothing wrong with that.

My question was more conceptual, a sort of a "What-if". I didn't find such scenario in the documentation and on my experience it is quite common in real life.

I understand the situation better.  Thanks for clarifying.  

Yes, it is common in real life to have some products that rarely need anything changed (Product Z) while having others that are still developing (Product A).  In my experience, the situation is similar to what you are doing.  A Product Backlog is maintained for each of the products and at some point a Scrum Team will pull items from the Product Z's backlog instead of Product A's backlog.  It doesn't make fiscal sense to have a team dedicated to a product that rarely needs updates.  

It isn't exactly what the Scrum Guide describes in the framework but in reality it is common and there really isn't anything wrong with it.  You can still apply the Scrum framework in the scenario if you honor the events and artifacts.