LeSS (Large-Scale Scrum)

What it is

Large-Scale Scrum (LeSS) was created by Craig Larman and Bas Vodde as a deliberate counterpoint to heavy scaling frameworks like SAFe. Its core philosophy is simple: apply Scrum directly to multiple teams, and resist the urge to add process.

The framework insists on:

• One Product Owner
• One Product Backlog
• One Definition of Done
• One integrated Increment per Sprint

Teams are organised as feature teams — cross-functional, cross-component, and able to deliver end-to-end customer value. There are no handoffs, no coordination teams, and no Release Train Engineers.

When to use it

Use LeSS when…	Consider alternatives when…
You have 2–8 teams working on a single product	Your organisation has strong command-and-control culture that won't tolerate autonomy
You want to preserve Scrum's simplicity at scale	You need heavyweight compliance, audit, or governance layers
Your organisation values empirical process control and self-management	Teams are split across multiple unrelated products
Your leadership is genuinely willing to remove organisational barriers	You need a framework that provides prescriptive process out of the box

Key concepts

Feature Teams

Every team is a feature team — able to deliver a complete, customer-visible feature in a single Sprint. This eliminates dependencies, handoffs, and the delays caused by component-team structures.

One Backlog

All teams pull from a single, prioritised Product Backlog. The Product Owner is accountable for overall prioritisation. Teams self-select items based on capacity, learning, and need.

Sprint Planning in Two Parts

Part One brings all teams together with the Product Owner to understand priorities and identify coordination needs. Part Two is team-level planning where each team decides how to deliver their selected items.

Whole-Product Focus

LeSS emphasises that all teams share accountability for the entire product — not just their slice. The Sprint Review involves all teams and stakeholders together, reinforcing this shared ownership.

Common pitfalls

Pitfall	Why it happens	How to avoid it
Implementing without mastering single-team Scrum	Management wants to "go agile" at scale immediately	Ensure each team can deliver a Done Increment before adding more teams
Keeping component teams	Existing specialists resist cross-training	Invest in skills development; restructure around features not components
Not having a strong enough Product Owner	PO role is given to someone without authority or time	The PO must have real decision-making power and be dedicated to the role
Underestimating organisational change	LeSS looks simple on paper	Treat it as a multi-year transformation, not a framework rollout
Using LeSS as a label while maintaining old structures	Renaming is easier than restructuring	Be honest about what is actually changing; inspect and adapt ruthlessly

NZ context

In New Zealand, LeSS appeals to companies that want to scale agile without importing the bureaucracy of larger overseas frameworks. The local preference for flat hierarchies and pragmatic problem-solving aligns well with LeSS's minimal-process ethos.

Career level guidance

Level	What to know	What to demonstrate
Junior	Understand what LeSS is and why it exists	Can explain the difference between LeSS and single-team Scrum
Intermediate	Know the key rules and roles	Can participate effectively in multi-team Sprint Planning and Reviews
Senior	Deep understanding of organisational design and feature teams	Can coach teams and management through the structural changes LeSS requires
Test Lead / QA Lead	Understand testing across multiple teams with one Definition of Done	Can design shared testing strategies and guide teams toward a unified quality bar