Seeing the system dynamic: 1 vs. n product backlogs

In a product organization with multiple teams, it raises a choice - whether to have one or many product backlogs. They usually start with one product backlog, either because they start with one pilot team, or because their product starts small from one team. Later, some organizations choose to have many product backlogs in response to more teams, while other organizations choose to keep one product backlog. When having many product backlogs, usually separate PO will be responsible for each backlog.

The below CLD illustrates the system dynamic around this topic.

Drive for one product backlog

As this is one product, it should be quite natural to think of one product backlog. The R1-loop reads like this.

• the fewer product backlogs
• the more transparency
• the better product wholeness
• the fewer product backlogs

Potentially this could be a virtuous cycle, which eventually leads to one product backlog.

Why having many product backlogs?

Then, why do some organizations choose to have many product backlogs? There are three main balancing loops in play, which are B1-loop, B3-loop and B5-loop. Together with R1-loop, it creates "limits to growth" system archetype.

B1-loop reads like this:

• the fewer product backlogs
• the bigger skill gap
• the lower development efficiency
• the more anxious team gets
• the more product backlogs

B1-loop illustrates the limitation from team specialization. In order to make use of team's specialization for efficiency, product backlog essentially becomes team backlog to match their skills. This dynamic is similar as the one involved in having generic vs. specialized teams. However, there is fundamental solution, and we shall elaborate on it later.

B3-loop reads like this:

• the fewer product backlogs
• the more stories in each backlog
• the more effort by PO on clarification (assumption: PO does requirement clarification)
• the more anxious PO gets
• the more product backlogs

B3-loop illustrates the limitation from requirement clarification. There is common misunderstanding about PO clarifying requirements for teams. If PO does all of that, it becomes a limiting factor for having one product backlog. However, there is fundamental solution, and we shall elaborate on it later.

B5-loop reads like this:

• the fewer product backlogs
• the more coupled among teams
• the less efficient in discovery and decision making
• the more anxious PO gets
• the more product backlogs

B5-loop illustrates the limitation from discovery and decision making. The assumption here is that every team has its own PO, and it is more efficient when PO could make decisions on his own. However, there is fundamental solution, and we shall elaborate on it later.

These are main restraining forces for having one product backlog. They limit R1-loop and damage the product wholeness. The leverage lies at weakening those forces by looking for fundamental solutions.

Look for fundamental solutions

Corresponding to B1-loop, B3-loop and B5-loop, there are alternative fundamental solutions shown as B2-loop, B4-loop and B6-loop, respectively. However, those solutions are with delay, thus, long-term. The short-term solution (i.e. having many product backlogs) shifts the focus on long-term solutions. That is essentially what "Shifting the burden" system archetype is about.

1. Team specialization

The fundamental solution is shown as B2-loop, which reads like this:

• the lower development efficiency
• the more anxious team gets
• the more learning
• the broader team skill gets (with delay)
• the smaller skill gap
• the higher development efficiency

Instead of having many product backlogs to reduce skill gap for development efficiency, we focus on learning and expanding team skill breadth, eventually leading to higher development efficiency.

R2-loop is the addictive loop in "Shifting the burden", which reads like this:

• the more product backlogs
• the less perceived need for learning by team
• the less learning
• the narrower team skill gets (with delay)
• the bigger skill gap
• the lower development efficiency
• the more anxious team gets
• the more product backlogs

When having many product backlogs sort of fixes the development efficiency, we tend to focus less on learning and expanding team skill breadth, and become more addictive to having many product backlogs.

2. Requirement clarification

The fundamental solution is shown as B4-loop, which reads like this:

• the more effort by PO on clarification
• the more anxious PO gets
• the more involved team gets in requirement clarification
• the less effort by PO on clarification (with delay)

Instead of having many product backlogs to reduce PO effort, we focus on getting team involved in requirement clarification, eventually leading to reduced workload from PO side. The delay is caused by team having to learn how to work with users and the domain in order to do the proper requirement clarification.

R3-loop is the addictive loop in "Shifting the burden", which reads like this:

• the more product backlogs
• the fewer stories in each backlog
• the less perceived need for help by PO
• the less involved team gets in requirement clarification
• the more effort by PO on clarification (with delay)
• the more anxious PO gets
• the more product backlogs

When having many product backlogs sort of fixes PO effort problem, we tend to focus less on getting team involved in requirement clarification, and become more addictive to having many product backlogs.

3. Discovery and decision making

The fundamental solution is shown as B6-loop, which reads like this:

• the less efficient in discovery and decision making
• the more anxious PO gets
• the more alignment across teams
• the more efficient in discovery and decision making (with delay)

Instead of having many product backlogs to reduce team coupling for discovery efficiency, we focus on getting teams aligned and increasing the capability of group decision making, eventually leading to more efficient discovery with group of teams and POs. The delay is due to the time and effort necessary to create cross-team alignment and build group collaboration capability.

R4-loop is the addictive loop in "Shifting the burden", which reads like this:

• the more product backlogs
• the less coupled among teams
• the less perceived need for alignment across teams
• the less alignment across teams
• the less efficient in discovery and decision making (with delay)
• the more anxious PO gets
• the more product backlogs

When having many product backlogs sort of fixes discovery efficiency problem, we tend to focus less on creating alignment and building group collaboration capability, and become more addictive to having many product backlogs.

Summary

As we have one product, it is desirable to have one product backlog. We look at what prevents us from doing that. Those are barriers we need to overcome. There are three common reasons why having many product backlogs - team specialization, requirement clarification, discovery and decision making. We look at fundamental solutions for those, and how to avoid the traps associated with the quick fix, i.e. having many product backlogs.