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.

Organize work - 1 vs n backlog - 1.png

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.

Organize work - 1 vs n backlog - 2.png

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

Organize work - 1 vs n backlog - 3.png

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

Organize work - 1 vs n backlog - 4.png

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

Organize work - 1 vs n backlog - 5.png

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.

Read more

จักระกับระบบประสาท

จักระกับระบบประสาท

ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai