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.
- critical customer bugs
- product A release 2.0
- other customer bugs
- product B feature 12
- critical/major internal bugs
- customer project A1 (based on product A)
- product A release 2.5
- product B other features
- product A prototype based on new hardware architecture
- 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.
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.
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!
