Priority guideline

Our goal is to have one product backlog and all teams are working in its priority order to maximize the customer value. Our current reality is that each team has its own backlog and the so-called one product backlog is actually a collection of many backlogs.

A desired backlog

In the article "The path of least resistance towards one backlog", I suggested to create a desired backlog, which defines the priority that we want assuming no constraint. The actual backlog defines the priority we really follow by taking our constraints (e.g. this team can only do this work) into consideration. The gap between them creates the tension, which drives towards one backlog through reducing the number of backlogs, disrupting the current team boundary, and etc. However, we face two major challenges in creating the desired backlog.

One challenge is lack of motivation to do it, as the actual backlog is sufficient to keep teams busy. This indicates lack of organizational vision to maximize customer value and continuously improve. Therefore, the status quo with collection of backlogs remains and we even pretend that it is the one backlog.

The other challenge is lack of ability to do it, as what is important from the whole product perspective is difficult to answer. This indicates lack of shared product vision and lack of product leadership. A priority guideline could be a first step for the change.

A priority guideline

Comparing to a desired backlog, a priority guideline is easier to create while still serves our purpose, which is to create the tension necessary to drive towards one backlog.

What is a priority guideline? It is a priority list with the whole product focus. Here is an example.

  1. critical customer bugs
  2. product A release 2.0
  3. other customer bugs
  4. product B feature 12
  5. critical/major internal bugs
  6. customer project A1 (based on product A)
  7. product A release 2.5
  8. product B other features
  9. product A prototype based on new hardware architecture
  10. product C ...

In this list, there is more than one product involved. The reason is that many organizations define their products too narrowly and in LeSS they are all parts of a broader product definition.

In essence, the priority guideline is a backlog of coarse-grained items, which is dynamic and updated regularly to reflect the current priority. Moreover, this is a simplified version of desired backlog, rather than actual backlog, as the order of real work is not exactly following the one in priority guideline, which is anyway a guideline.

The key is ... the tension

We could further evolve priority guideline into desired backlog. We make the items in priority guideline more fine-grained, e.g. in terms of epics. By the way, in practice I try to avoid the term epic, as it often introduces unnecessary complexity and confusion. To me, those are all stories or just items, big or small.


On the other hand, it may be sufficient to let priority guideline drive towards one actual backlog, as the gap between priority guideline and actual backlog may already serve the purpose of creating the tension. Referring to the above picture from the "The fifth discipline" book, both desired backlog and priority guideline act as your vision, while actual backlog is your current reality. The gap between them creates the tension necessary to drive towards one backlog.

Product backlog and Area backlogs

Taking the above view, let's look at product backlog and area backlogs in LeSS Huge.

1. Simple case - items in product backlog and area backlogs have the same granularity.

Area backlog - simple.jpg

As the real work is done according to the priority in those area backlogs, the collection of area backlogs is in fact the actual backlog. Then, what is the product backlog? It is in fact the desired backlog. The gap between them is very visible, which creates the tension for change - requirement areas are dynamic!

2. Complex case - items in product backlog and area backlogs have different granularities.

Area backlog - complex.jpg

Similar to the simple case, the collection of area backlogs is the actual backlog, while the product backlog is the desired backlog. The difference is that items in product backlog are more coarse-grained than those in area backlogs. Nevertheless, it still shows the gap thus creates the tension for change. What's interesting is, as items in product backlog get more coarse-grained, the product backlog devolves into a priority guideline!

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