From Top 3 to Pie Chart

Ultimately, we want to have one product backlog for the whole organization in order to optimize value globally. However, the current reality is often lack of global priority, with many local backlogs. What could be practical next steps in order to gradually establish global priority?

I have been suggesting to start from defining top 3 or a priority guideline. However, I find it only effective in some cases. In this article, I'd like to explore the reasons and provide the alternative - pie chart.

Top 3

When suggesting to first define top 3, I have the below further changes in mind:

  • from top 3 to top 10, 20... then the product backlog emerges
  • have more people focus on those top items, thus, deliver more value as whole organization.

However, what actually happens is often different. Once top 3 becomes visible, it does increase the awareness about global priority. All related people do take these as highest priority. But there is little impact on others, whose work is not related to top 3. Why?

The organization is structured with various specialty areas, be it functions, components or customer domains. There are essentially many local backlogs, and the real work only follows the local priority. Even though everybody knows what top 3 items are, it doesn't change anything.

What is wrong with this? Aren't top 3 items already proceeding as highest priority? We need to step back and see the big picture. Looking at the whole development capacity in the below picture, we find that perhaps only 20% of people work on top 3, while the remaining 80% of people work on other things. What is the priority of other things? They are not in top 3, thus lower priority, but as they are being worked on, practically they have the same priority as top 3.

from top3 to pie chart - 1.jpg

So, the defined global priority does not become the actual one by itself, and we need to respond to them - focus on getting them done as whole organization.

In my experience, the defined top 3 items are usually big. They are close to the traditional project size, i.e. 3 top items may be 3 top projects. Can we get the 1st item done before working on the 2nd and the 3rd, assuming that those items are already minimally valuable? If we are in smaller large-scale case (e.g. 30 people), it is feasible. This way, we evolve from top 3 to one backlog and one priority for the whole organization.

Nevertheless, there are limits to one backlog coming from both PO and team. Please see the full analysis in the series of "Limits to one Product Backlog". When we are in larger large-scale case (e.g. 150 people), we may end up with a few areas each having a few teams sharing one area backlog. Top 3 is not effective in guiding the priority across those areas, then comes pie chart.

Pie Chart

Pie chart shows how the overall development capacity is distributed, in terms of people or teams. Pie chart reflects the priority in a coarse granularity, and it is similar to an investment portfolio. The below picture is an example for an 150-people organization, distributed among 5 areas. Furthermore, same as product backlog, pie chart is also prone to change, but less frequently than backlog items.

from top3 to pie chart - 2.jpg

So, instead of asking what top 3 are, we ask how you want to distribute your whole development capacity.

If you already structure your development organization into feature teams, then, the pie chart shows how many teams in each area. With the appropriate size of areas, this is essentially a snapshot of RAs (Requirement Areas). While the overall PO manages the life cycle of RAs, he could in practice be managing the pie chart.

If your current structure is not yet feature team based, the initial distribution is based on number of people. Then, we look for the opportunity to create the first RA - establish multiple feature teams and have them share one area backlog.

As the transformation of the whole organization into feature team based is a gradual process, it is very likely that in the middle of that change, we also need to change the pie chart. When that happens, we both move existing teams and establish new feature teams to reflect the priority change in the updated pie chart, until eventually pie chart becomes RA view.


Size matters. In smaller large-scale case (i.e. LeSS), we may start with top 3 - what are the most valuable work. In larger large-scale case (i.e. LeSS Huge), we may start with pie chart - how do we distribute our development capacity?

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai