A bunch of teams are responsible for various domains, be it systems or services. Each domain team has its own backlog. For example, in an e-commerce company, there are domain teams responsible for website, OMS (Order Management System), WMS (Warehouse Management System), payment system, etc. They develop features from those
There are a few teams each having its own PO (Product Owner), is there a need for an overarching PGO (Product Group Owner)? I have recently encountered two different configurations, and let's explore them one by one. 1. Teams are responsible for elements in the product In the
"We have 5 teams. We are doing LeSS, and we have 3 APOs (Area Product Owners)." Wait, this is NOT LeSS! Motivated by this kind of common misunderstanding, I am writing this article to describes the different rules in LeSS and LeSS Huge, and why they are different.
In the previous two articles, we explored the limits from PO (Product Owner) on clarification and prioritization respectively. In this article, we shall look at the limit from teams. Team's capability on development Similar to the limit from PO, we are also limited by team's capability
In the previous article, we explored one of the two limits from PO - the fake limit on clarification. In this article, we shall explore the other limit from PO - the real limit on prioritization. Real limit on prioritization Besides the limit on clarification, the other limit is PO&
What are the limits to one PBL (Product Backlog)? Two major areas are from PO (Product Owner) and team, respectively. We shall first focus on the limits from PO. When people claim that it is impossible for one PO to manage one PBL shared by many teams, there are actually
The previous article was written in an analytical manner, while in this article I will supplement it with an experience during the time of Nokia Networks. As it happened more than ten years ago, some details may not be as accurate as I would like them to be, but I
Recently, I ran across my old article "PO on team or PO on feature?" written about ten years ago, and found that it could be connected to the topic of limits to one product backlog. My thinking at that time touched some factors, but was still vague. Over
[RA = Requirement Area; PBI = Product Backlog Item.] In LeSS Huge, there is an additional scaling technique called RA. How to define RAs has confused many practitioners. This article tries to open a perspective. By which dimension? By which dimension do we define RAs? We know that RA is customer centric.
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
In large-scale product development organization, %(people in special roles) is a good indicator for the degree of self-organization in teams. Special roles in this measure are outside teams. There is no special role inside teams, as everybody takes the role of team member. Sometimes, the team may define "special
Frameworks as starting point If you look at the LeSS complete picture, you see that the frameworks - defined by the rules - and the principles are at the heart of LeSS. However, this is not completely true. In fact, the LeSS frameworks emerged out of the experiments, in response