ZeroBlockers vs LeSS / LeSS Huge
One backlog for every team, or one part of the journey per team.
What it is
Many feature teams, one Product Owner, one backlog
LeSS applies Scrum to many teams working on one product. It uses long-lived, cross-functional feature teams, one Product Owner and one shared Product Backlog. LeSS Huge adds requirement areas, each with an Area Product Owner, for products with more than eight teams.
Where it breaks
Every team’s next item competes for the top of one list
In LeSS, one Product Owner ranks one backlog for the whole product, and teams take their next items from it. That makes it easy to point many teams at the most important item.
It also means a team can work in a different part of the product each Sprint, in code and with customers it has not worked with before, and the ranking of every team’s work sits with one person.
You will often see
- Teams switch product areas from Sprint to Sprint.
- Every team waits on one Product Owner.
- No team knows its customers deeply.
How ZeroBlockers fixes it
Each team owns a part of the journey and picks its next work
Who carries the work from idea to satisfied customer
| Strategy and funding | Discover the problem | Test solutions | Build | Release | Run and measure | |
|---|---|---|---|---|---|---|
| LeSS / LeSS Huge | Product Owner | Teams clarify with users, and the Product Owner decides | Feature teams | |||
| ZeroBlockers | Product Team | Stream Team | ||||
LeSS / LeSS Huge
- Strategy and fundingProduct Owner
- Discover the problemTeams clarify with users, and the Product Owner decides
- Test solutions to Run and measureFeature teams
ZeroBlockers
- Strategy and fundingProduct Team
- Discover the problem to Run and measureStream Team
In ZeroBlockers, each team owns one part of the customer journey for the long term, has its own funding, and decides its own next work against agreed outcome targets. It knows its customers and its code deeply.
ZeroBlockers gives up some of the flexibility of one backlog. Moving capacity between parts of the product takes a deliberate funding decision.
The usual reply
“Internal Product Teams are component teams by another name.”
LeSS practitioners will say that any team dedicated to a shared service creates the handoffs feature teams exist to remove. They will add that one backlog lets the whole product change direction quickly.
This is the strongest objection, and it holds whenever the internal team takes requests. ZeroBlockers sets a test: if other teams still have to ask, the service has failed and needs redesign. The trade on the single backlog is real. ZeroBlockers gives up some flexibility to get teams that know their part of the journey deeply. Where the whole product changes direction often, LeSS may fit better.
01 / Side by side
How the approaches differ
- ProcessHow work moves from idea to live use
LeSS / LeSS Huge
Teams work in shared Sprints and clarify items directly with users. The Product Owner decides what to build, and LeSS does not prescribe a way to test ideas before building.
ZeroBlockers
Each team runs weekly customer research and cheap tests, and chooses its own next work against outcome targets.
- StructureWho is on the team
LeSS / LeSS Huge
Feature teams that can take items from anywhere in the product, or anywhere in their requirement area.
ZeroBlockers
Each Stream Team stays in one part of the customer journey and learns its customers and code deeply. Shared services get their own teams with stable interfaces.
- GovernanceHow success is judged and who decides
LeSS / LeSS Huge
The Product Owner ranks the work and judges its value, and teams deliver a shippable product increment every Sprint.
ZeroBlockers
Outcome targets, each paired with a quality measure, are reviewed every week, and each team decides its own next work within them.
- FundingWhether the scope gets locked
Shared
Neither locks the scope. LeSS reorders one backlog every Sprint, and ZeroBlockers funds each team for a part of the customer journey with no feature list.
- AlignmentHow many teams stay aligned
LeSS / LeSS Huge
One Product Owner ranks one backlog for the whole product, so the teams stay aligned through a single list. In LeSS Huge, Area Product Owners rank each requirement area.
ZeroBlockers
Leaders set the strategy and outcome targets, and each team chooses its own work within them. Moving capacity between parts of the product is a deliberate leadership decision.
- ScalingSkills and the rest of the business
LeSS / LeSS Huge
Communities of practice connect each discipline across feature teams, and any team can change any shared code.
ZeroBlockers
Enabling Teams coach each discipline, and functional leads own careers. Shared services become self-service products with their own teams, so no team waits on another.
02 / Why it differs
The differences explained
LeSS ranks all the work in one list
The LeSS rules call for long-lived, cross-functional feature teams, one Product Backlog, and one Product Owner. LeSS Huge splits the backlog into requirement areas, each with an Area Product Owner. Each area groups related customer needs.
A single list lets the Product Owner move every team onto the biggest opportunity. LeSS Huge groups teams by requirement area. Within an area, though, no team owns a part of the journey, and its next item can land in code and with customers it has not worked with before.
That list also has one owner. When AI lets every team finish work faster, the Product Owner has to rank and explain more items for every team at once. LeSS expects teams to clarify items directly with customers, which helps. The ranking still sits with one person.
A ZeroBlockers Stream Team is a small, persistent team that owns one part of the customer journey, such as search or booking. The Product Team, the leadership group for the product, agrees outcome targets and funding for each part. The Stream Team then picks its own experiments. It does not compete with other teams for the top of a shared list.
Owning a part must not mean ignoring the whole
LeSS’s customer-centric guidance connects teams directly to customers and keeps the whole product in view. ZeroBlockers needs the same discipline. A Search Team that doubles clicks has failed if those travelers never book.
In ZeroBlockers alignment, the Product Team sets one strategy, such as winning business travelers, and agrees targets with Search and Booking that point the same way. The Weekly Product Review checks what each change did to completed bookings. When two teams’ targets pull against each other, the Product Team fixes the targets.
Teams must be able to release without their neighbors
A team can understand a whole customer problem and still need three other teams to change their code before it can ship. LeSS pushes to simplify the organization and grow broad skills in every team. ZeroBlockers takes a different view of shared code.
This is a real disagreement. LeSS avoids component and platform teams because they create the handoffs feature teams were meant to remove. ZeroBlockers accepts an Internal Product Team for a shared service when many teams keep making the same request, and holds it to a self-service standard. If teams still have to ask it for changes, the service has failed.
ZeroBlockers ties ownership to persistent funding and to the team’s own authority to release. A shared payment service gets its own Internal Product Team, which runs it as a self-service capability with a stable interface. The Booking Team can then improve checkout without asking for a custom platform change each time.
Sources and comparison scope
Reviewed September 2026. This page compares ZeroBlockers with LeSS / LeSS Huge as documented, with attributed practitioner accounts where available. Descriptions of LeSS / LeSS Huge follow its published guidance. Claims about common practice are attributed where they come from a named source. Other statements about what organizations typically do are our analysis. The worked example is our analysis and reports no measured results.