Which guidelines are applicable for a single Scrum Team managing multiple backlogs?

Question

Does the Agile community have recommended processes for a single Scrum Team managing tasks coming in from multiple backlogs?

Context and Problem

• One Scrum Team
• One Scrum Master
• Delivering value to an Enterprise Organisation (+10,000 employees, +$2billion revenue)
• Tasks come into the Team from each Business Function (Sales, Marketing, Customer Service, etc)
• 2 week sprints
• Senior Management (Steering Board) review Scrum effectiveness monthly
• Tasks will be ongoing for at least the next 3 years as part of a massive Change Management implementation enterprise-wide
• The Scrum Team has a developer from each Function which knows the Function intimately but not necessarily what they are going to request from the Scrum Team
• In addition to Functional Requests the Scrum Team also have other demands from ad-hoc Projects (which have a Project Manager but not a Product Owner)
• Scrum Team still has tribal mentality of "I am a Sales Developer and he is a Marketing Analyst. I put more points on the board than he did and he only worked on stories for his buddy in Marketing."

Considered Solution

My current plan is for the following action to take place (but I am happy to have the process reviewed by the SE community)

• Each function present their requirements as part of a Function Backlog
• Each function is responsible for grooming their own backlog and having a Product Owner
• Function requirements must be in the form of User Stories (basic level)
• A member of each function attend the Sprint Plan to argue their prioritization over the other Functions (no more than 30 mins time)
• The most compelling business case wins (prize = approx 30-50% of the Sprint Plan)
• The remainder of the Sprint Plan is dedicated to any High Priority functional item from any Function with an even split between Functions (Any Sales, Customer Service or Marketing M or S user story on the MoSCoW scale can be included.)

Personal Opinion

I cannot imagine a fairer way of bringing together equal Functions with fluctuating Business cases from Sprint to Sprint.

Considerations

Luckily, all of the requirements are based in the same development environment centered around SAP functionality so the development team (and testing) does not massively vary between user stories/function. What Marketing ask for is well within the sphere of what Customer Service will ask for; just a different end user.

All that changes is which stakeholder gets the value at the end of the Sprint, which department gets the asset added to their bottom line and who gets the bill for the Scrum Team.

Request

Happy to accept any thoughts, white papers or guidance from the Community.

In addition, I have really tried to frame this question for SE so please drop a line if the format is useful including explanations etc.

Answer 1

TL;DR

Does the Agile community have recommended processes for a single Scrum Team managing tasks coming in from multiple backlogs?

Sure: don't do it.

Multiple teams can work from a single Product Backlog, but never the other way around. A single team working from multiple Product Backlogs isn't Scrum, isn't agile, and is extremely unlikely to work at any scale.

First, determine whether you have a single unified project or many separate (although possibly related) projects. Once you nail down that critical datum, you can redesign your project management processes accordingly.

The Product Backlog Must Be Unary

Within the Scrum framework, there is always a a one-to-one relationship between:

• a project and a Product Backlog;
• a Product Backlog and a Product Owner;
• a Scrum Team and a Product Owner;
• a Scrum Team and a Product Backlog.

While there are ways to scale Scrum across multiple teams and projects such as a Scrum-of-Scrums or SAFe, your Scrum implementation has gone off the rails if you are funneling more than one Product Backlog directly into a single Scrum Development Team.

Unified Project: Many Stakeholders, One Backlog

The situation you're describing, where there are many stakeholders with different agendas, is actually quite common. Assuming that you have a single project with a reasonably-unified aim, the correct way to deal with this within the Scrum framework is to treat each of these business interests as stakeholders, and allow the Product Owner to manage a unified Product Backlog in whatever way seems most appropriate to balance the interests of the stakeholders.

The Product Owner can use techniques likes Theme Scoring or Relative Weighting to assist the stakeholders in balancing their interests, but the singular Product Owner ultimately creates a single, sequenced Product Backlog for the Scrum Team to work from. This is absolutely fundamental to the framework, and is not negotiable if you want to call what you're doing "Scrum."

Multiple Projects, Multiple Teams

Another fundamental concept of Scrum, and agile frameworks in general, is that multitasking is bad because it creates task-switching overhead and reduces throughput and effectiveness. A project is generally defined as:

an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

If all of the business units are not working towards the same unified aim, then you don't have a unified project; you have multiple projects. Multiple projects require that you sequence your projects through one team, or distribute the projects across multiple teams. Either way, you should organize your project teams and project management framework to align with the reality that you don't have a single, cohesive project; pretending that you do will not put lipstick on the pig.

Answer 2

You need a full-time dedicated Product Owner for the Scrum teams

In one of my previous assignments, as the Scrum Master, I worked with a group of Product Managers similar to what you describe. Also, the Product Managers had many other priorities and so getting requirements clarifications or Customer Acceptance Testing (CAT) from them in a timely manner was hard. Each of the four Product Managers lobbied for getting more of the dev team's time for their features, similar to what you describe. However, my situation was better than yours in two aspects:

1. The lobbying happened in a Roadmap or Backlog Grooming meeting without the full dev team present.

2. Luckily one of the Product Managers was senior and could make the final call when it got contentious.

After doing that for more than a year, we got smarter and appointed a full-time dedicated Product Owner (for 3 Scrum teams). The Product Owner worked offline with the different Product Owners and fed the resulting unified priorities to the dev teams. The Product Owner also sat in the Sprint Planning meeting as well as was available to the dev team to clarify requirements across the table and do CAT testing at short notice. The improvement in team productivity and morale was dramatic.

Based on this experience, in my opinion, your considered solution won't work. At a minimum consider implementing 1 and 2 above. Better still name a full-time dedicated Product Owner.