LeSS (Large-Scale Scrum)
A lightweight scaling framework that applies Scrum principles to multiple teams working on one product, with minimal additional roles, rules, or processes.
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.
LeSS supports 2–8 teams on a single product. LeSS Huge extends this to up to thousands of people through an additional "Area Product Owner" layer, while still preserving the same minimalist principles.
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.
NZ technology firms with 3–5 Scrum teams on a single product often find LeSS more approachable than SAFe, especially when they already have experienced Scrum Masters and strong engineering practices in place.
Industry Reality
- Most organisations that claim to "run LeSS" have kept their component teams and middle-management layers intact, renaming them as "feature teams" without actually restructuring. Expect a gap between the label and the practice.
- The single Product Owner rule is the most frequently violated. In practice you'll often find a PO committee, a proxy PO, or a PO who reports to a portfolio steering group — all of which LeSS explicitly forbids.
- Senior practitioners treat LeSS primarily as an organisational design challenge, not a process question. The ceremonies are straightforward; convincing a business to eliminate middle management is the hard part.
- In NZ contexts with 3–5 teams, many organisations adopt the LeSS structure informally without a formal adoption programme — running a shared backlog and joint Sprint Reviews because it makes sense, not because they read the rulebook.
- True LeSS Huge adoption (beyond 8 teams) is rare in the NZ market. Most local exposure is to base LeSS or to hybrid arrangements that borrow selectively from the framework.
Context guide
How the right level of Large-Scale Scrum (LeSS) effort changes based on team context.
| Context | Priority | Why |
|---|---|---|
| Revenue NZ (Revenue NZ) running 3–5 teams on the myIR self-service platform, already practising single-team Scrum reliably | Essential | A shared Product Backlog prevents duplicate prioritisation across compliance-driven tax rules, and one Definition of Done ensures every increment meets Privacy Act 2020 handling requirements without a separate QA gate layer. |
| TeleNZ digital squad scaling from two teams to four teams on a single broadband product portal | Essential | Feature teams pulling from one backlog eliminate the negotiation overhead that emerges when separate squads maintain separate roadmaps for interconnected customer journeys (provisioning, billing, fault logging). |
| Harbour Bank modernising a legacy payments core with two new Scrum teams alongside an existing platform team | High | LeSS's single-increment model surfaces integration risk earlier than sprint-by-sprint handoffs; however, the legacy team's slower cadence may require an adjustment period before full shared-backlog discipline is viable. |
| Benefits NZ (Benefits NZ) building a new case management system, with an embedded vendor team alongside two in-house teams | Medium | LeSS's structural requirements (feature teams, single PO authority) are hard to enforce across organisational boundaries; a vendor contract that locks component scope makes true feature-team restructuring politically difficult. |
| TransitNZ (TransitNZ) programme with nine teams across two unrelated products — transport licencing and infrastructure reporting | Low | LeSS requires one product; running nine teams across two distinct products means two separate LeSS adoptions minimum, or LeSS Huge — neither of which suits this context without significant structural redesign. |
| CoverNZ running a multi-year CCCFA compliance remediation programme with strong governance board oversight and quarterly steering committee control | Low | A regulatory compliance programme where prioritisation decisions require steering board approval cannot support the empowered single-PO model LeSS depends on. SAFe Essential or a structured programme governance model is a better fit. |
Trade-offs
What you gain and what you give up when you adopt Large-Scale Scrum (LeSS).
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Whole-product visibility — one backlog forces trade-off decisions to be made explicitly at the product level, preventing teams from accumulating invisible technical debt or gold-plating low-priority features in isolation. | High structural overhead upfront — restructuring from component teams to feature teams requires cross-training investment, role changes, and organisational courage that many NZ organisations underestimate before committing. | You need to scale across more than eight teams — consider LeSS Huge, or evaluate whether the scope genuinely constitutes one product. |
| Minimal process addition — LeSS deliberately avoids new roles (no Release Train Engineers, no programme-level POs), which reduces coordination ceremony and lets teams stay focused on delivery. | Requires a genuinely empowered, full-time Product Owner — in NZ organisations where product ownership is shared across business analysts, managers, and governance boards, finding one person with that mandate is often politically infeasible. | Your organisation requires prescriptive audit trails and governance artefacts — SAFe's built-in programme ceremonies and RACI structures are a better match. |
| Continuous integration of quality — because all teams work towards one integrated Increment per Sprint, integration defects surface within the Sprint rather than accumulating until a release phase. | Amplifies existing Scrum weaknesses — if individual teams cannot reliably produce Done Increments, LeSS multiplies that failure across all teams simultaneously, making root causes harder to isolate and fix. | Teams are new to Scrum or still building basic delivery discipline — establish single-team maturity first, then consider LeSS once each team can ship independently. |
| Flat organisational signal — LeSS's elimination of middle-management coordination layers aligns with NZ's cultural preference for direct communication and flat hierarchies, reducing meeting overhead compared to SAFe programme rituals. | Difficult to retrofit over existing structures — most NZ enterprises starting LeSS already have component teams, project managers, and steering committees; dismantling those structures is a multi-year change management effort, not a framework swap. | The organisation cannot commit to structural change within 6–12 months — consider a Scrum of Scrums arrangement as an interim coordination model until appetite for restructuring grows. |
Enterprise reality
How LeSS behaves at 200–300-developer scale in NZ enterprise — banks, government, telcos
- Shared Product Backlog governance is automated: at organisations like CloudBooks, backlog refinement tooling (Jira Advanced Roadmaps or Azure DevOps Plans) enforces dependency mapping and cross-team capacity rules that small teams handle informally — without it, a 12-squad shared backlog becomes unmanageable within two Sprints as teams create duplicate items and silent priority conflicts.
- Privacy Act 2020 and NZISM compliance obligations mean government agencies running LeSS (such as Revenue NZ or HealthNZ) cannot rely on a single Definition of Done authored by feature teams alone — security architects and privacy officers must co-author DoD criteria covering data classification, audit logging, and access controls, adding a governance layer that base LeSS does not prescribe but enterprise risk frameworks require.
- At 10+ squads, cross-team integration testing volume exceeds what manual coordination can handle: banks such as Harbour Bank typically run a dedicated CI/CD platform team (not a LeSS team itself, but a supporting function) maintaining trunk-based pipelines in GitHub Actions or Harness, with automated contract testing via Pact to catch breaking API changes before they cascade across feature teams — skipping this infrastructure means integration failures cost an entire Sprint's output across multiple teams simultaneously.
- Multi-timezone coordination breaks LeSS's assumption of collocated or near-collocated teams: NZ telcos like Spark and 2degrees with offshore development partners in the Philippines or India find that Sprint Planning Part One — designed as a live joint session — either balloons to three hours covering all timezones, or fragments into async pre-work that undermines the shared-context purpose; organisations that do not address this explicitly see cross-team dependency resolution slip from intra-Sprint to inter-Sprint, introducing delays LeSS was designed to eliminate.
◆ What I would do
Professional judgment — when to adopt Large-Scale Scrum (LeSS), when to adapt it, and what to watch for.
The bottom line: LeSS succeeds or fails at the organisational design level, not the ceremony level — your most important job as a tester in a LeSS adoption is to make the structural gaps visible with evidence, then use the Overall Retrospective to turn them into impediments with owners.
Best Practices
- ✓ Master single-team Scrum thoroughly before attempting LeSS — every team must be capable of producing a Done Increment independently before you add the coordination complexity of multiple teams.
- ✓ Insist on a real Product Owner who has the authority, time, and product knowledge to manage a single backlog across all teams — a part-time or consensus-by-committee PO breaks the model.
- ✓ Use Overall Retrospectives (involving representatives from all teams) to surface systemic impediments that individual team retros can't resolve — this is where organisational change actually happens.
- ✓ Build shared Definition of Done criteria with input from all teams, and review them at least every few Sprints as teams' capabilities improve.
- ✓ Invest in shared engineering practices — trunk-based development, continuous integration, and automated test suites — before scaling; without these, multi-team integration becomes a bottleneck.
- ✓ Rotate team members across features deliberately to spread knowledge and avoid the component-team anti-pattern reasserting itself through informal specialisation.
- ✓ Keep the multi-team Sprint Review focused on the integrated Increment rather than team-by-team demos — this reinforces whole-product thinking and surfaces integration gaps early.
- ✓ Treat every organisational impediment surfaced in retrospectives as a backlog item with an owner and a target date — LeSS requires management to actively remove structural barriers, not just acknowledge them.
Common Misconceptions
❌ Myth: LeSS is just Scrum with more teams running in parallel
Reality: LeSS is an organisational redesign that happens to use Scrum as its foundation. The critical change is restructuring from component teams to feature teams and establishing true single-backlog governance — running multiple Scrum teams without those structural changes produces coordination chaos, not LeSS.
❌ Myth: LeSS is simpler and faster to adopt than SAFe because it has fewer rules
Reality: Fewer rules makes LeSS harder to adopt, not easier. SAFe provides a detailed implementation playbook that organisations can follow step by step. LeSS requires leadership to make difficult structural decisions — eliminating roles, redesigning teams, empowering a single PO — without a prescriptive guide. It demands more organisational courage and judgment, not less.
❌ Myth: As a tester, LeSS doesn't change my day-to-day work much
Reality: LeSS significantly changes the testing function. There is no central QA team or release testing phase — each feature team is responsible for its own quality, end-to-end. Testers must collaborate directly with developers across potentially unfamiliar components, contribute to a shared Definition of Done, and help coordinate cross-team integration testing. The shift from specialist gatekeeper to embedded quality enabler is substantial.
Senior engineer insight
The teams that thrive in LeSS are the ones who treat the single Product Backlog as a forcing function for organisational honesty — when all five teams are pulling from the same list, the hidden dependencies and political backlogs that middle management have been quietly maintaining become impossible to hide. What separates them from teams that struggle is a willingness to let the framework surface those conflicts rather than papering over them with coordination meetings. The pattern that consistently works is starting the first Overall Retrospective with the question "what structural thing is stopping us from delivering as one product?" rather than "how did the Sprint go?" — it shifts the conversation from ceremony to root cause immediately.
The most common mistake: declaring LeSS adoption complete once the ceremonies are running. The ceremonies are the easy part — the hard part is dismantling the component-team structure and the middle-management coordination layer that LeSS makes redundant, and most organisations stop before they get there.
From the field
A NZ financial services firm running four Scrum teams on a shared payments platform adopted LeSS and ran a clean single-backlog structure for two Sprints before the wheels came off. The assumption was that feature teams could self-select backlog items freely — what no one had modelled was that two teams would simultaneously pull the same high-priority regulatory feature because both had relevant capability. They spent Sprint Planning Part Two in a standoff, each team reluctant to yield the high-visibility item. What changed was the Product Owner introducing a lightweight "team radar" session at the start of Part One — each team flagged which upcoming backlog items they had strongest delivery context for, and items with overlapping interest were clarified before selection began. The lesson that travels is that LeSS's self-organisation assumption requires shared information, not just shared intent: teams can't coordinate well on item selection if they don't know what each other is positioned to deliver.
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 |
Self-Check
Click each question to reveal the answer.
Q1: What is the single most structurally significant rule in LeSS?
One Product Owner, one Product Backlog, and one integrated Increment per Sprint across all teams. This single-backlog rule is what distinguishes LeSS from simply running parallel Scrum teams — it forces whole-product thinking and eliminates the siloed prioritisation that causes inter-team dependency chaos.
Q2: What is a feature team in LeSS, and why does it matter?
A feature team is cross-functional and cross-component — able to deliver a complete, customer-visible feature without requiring handoffs to another team. It matters because component teams (front-end team, back-end team, database team) create coordination overhead and inter-team dependencies that defeat the purpose of scaling agile. Feature teams eliminate that bottleneck by design.
Q3: How does Sprint Planning work differently in LeSS compared to single-team Scrum?
LeSS Sprint Planning has two parts. Part One brings all teams together with the Product Owner to understand priorities and identify where teams might need to coordinate. Part Two is team-level: each team plans how it will deliver its selected backlog items. This structure ensures shared context without removing team autonomy over the how.
Q4: When should an organisation seriously consider LeSS Huge rather than base LeSS?
When the number of teams exceeds eight, base LeSS with one Product Owner becomes impractical because no single person can hold sufficient product knowledge across that many teams. LeSS Huge introduces Area Product Owners, each responsible for a customer-centric area of the product, while still preserving one overall PO and one backlog at the product level. In the NZ market, LeSS Huge adoption is rare — most local implementations stay within base LeSS territory.
Q5: Why does LeSS insist teams master single-team Scrum before adopting LeSS?
Because LeSS adds coordination complexity on top of Scrum — it does not simplify it. A team that cannot reliably deliver a Done Increment in a single Sprint will produce integration failures, carry-over work, and dependency debt that cascades across all other teams. Scaling broken Scrum makes each problem harder to diagnose and fix, not easier.
Q6: Your organisation runs three Scrum teams building a shared Benefits NZ case management platform. Leadership wants to adopt LeSS but plans to keep the existing front-end team, back-end team, and data team structure. What is the core problem with this plan, and what would you recommend instead?
The existing structure is three component teams, not feature teams — each incapable of delivering a complete user-visible feature without depending on the others. LeSS explicitly requires feature teams; keeping component teams while calling the arrangement LeSS is the most common adoption failure. The result is that every backlog item requires coordination across all three teams, which means every Sprint produces handoffs, blockers, and integration risk rather than Done Increments. The recommendation is to restructure teams around customer-facing features of the Benefits NZ platform — for example, one team owns the full stack for case intake (from citizen-facing form through to case worker view and workflow triggers), another owns payments and entitlements end-to-end. This requires cross-training, which is investment — but without it LeSS cannot function as designed.
Q7: What is the key difference between LeSS and SAFe, and which would be more appropriate for a NZ government agency with strong audit and compliance requirements?
LeSS is a minimalist framework that adds as little process as possible on top of Scrum — no Release Train Engineers, no PI Planning, no Portfolio Kanban, no prescribed roles beyond those in single-team Scrum. SAFe is a comprehensive, prescriptive framework with defined ceremonies, roles, and governance artifacts designed to align large programmes and satisfy audit trails. For a NZ government agency with strong compliance requirements — say, an Revenue NZ or TransitNZ programme required to demonstrate controlled change management to the Office of the Auditor-General — SAFe's built-in governance structures and traceability artifacts are a genuine advantage. LeSS would require the agency to bolt compliance tooling on top of a deliberately minimal framework, which creates tension. LeSS is the better fit when the organisation has cultural autonomy and wants to avoid bureaucracy; SAFe is the better fit when external oversight demands documented process.
Q8: A Scrum Master says "We're using LeSS — each of our five teams has its own Product Owner who prioritises their team's backlog." What is wrong with this, and how do you explain why it violates LeSS's core model?
LeSS requires exactly one Product Owner and one shared Product Backlog across all teams. Five team-level POs with five separate backlogs is Scrum of Scrums territory at best, or simply five parallel Scrum teams at worst — not LeSS. The single PO rule exists to enforce whole-product prioritisation: if each team has its own PO, teams will optimise for their own slice of the product, dependencies will be negotiated informally, and the integrated Increment will reflect five competing priority lists rather than one coherent product strategy. The Scrum Master is likely describing either an immature LeSS adoption that kept existing team structures, or a genuine Scrum of Scrums being mislabelled as LeSS. The fix is to consolidate backlog ownership into one PO who has the authority and time to manage priorities across all five teams.
Q9: Give an example of when you would advise against adopting LeSS even if the team count (2-8) is within range, and what would you suggest instead?
LeSS is the wrong choice when the organisation has a command-and-control culture that cannot genuinely empower a single Product Owner or tolerate self-managing teams. For example, a NZ bank running a regulatory compliance programme — such as a CCCFA or AML/CFT remediation — may have legal, risk, and audit stakeholders who all expect to direct prioritisation. In that context, a single empowered PO making unilateral backlog calls is politically impossible, and the continuous management intervention that LeSS forbids is actually required by the governance model. Adopting LeSS under these conditions produces an org chart that says LeSS but behaves as a waterfall with Scrum ceremonies bolted on. A better fit is a Scaled Scrum approach with explicit governance checkpoints, or SAFe's Essential tier which accommodates steering-committee oversight. LeSS requires genuine organisational courage to work — if that courage isn't present, the framework will be hollowed out within a quarter.
Why teams fail here
- Adopting LeSS labels without restructuring teams — renaming a front-end team a "feature team" while keeping the same component boundaries means every backlog item still requires inter-team handoffs, and LeSS's coordination model has no mechanism for managing them
- Installing a weak or part-time Product Owner — LeSS places enormous decision-making authority in a single person; a PO who defers to a steering committee or manages the role alongside another job will create backlog paralysis across all teams simultaneously
- Skipping the Overall Retrospective or running it as a status report — this is the only LeSS ceremony explicitly designed to surface and address systemic organisational impediments; treating it as a Sprint retro recap means structural problems accumulate until they force a crisis
- Attempting LeSS without shared engineering infrastructure — multi-team integration with separate CI pipelines, divergent branching strategies, or manual merge gates means the integration work that should happen continuously inside each Sprint gets deferred to a painful end-of-Sprint crunch that worsens with every additional team
Key takeaway
LeSS done well is not a scaling framework bolted onto Scrum — it is an organisational redesign that uses Scrum's discipline to expose and eliminate every structure that prevents multiple teams from behaving as one.
How this has changed
The field moved. Here is how LeSS (Large-Scale Scrum) evolved from its origins to current practice.
Craig Larman and Bas Vodde begin developing LeSS while consulting at Nokia. Core insight: most scaling problems are organisational, not process problems. Scaling should preserve Scrum's simplicity rather than add complexity.
LeSS published in "Scaling Lean and Agile Development" — one Product Owner, one Product Backlog, one potentially shippable increment per sprint, multiple feature teams.
LeSS Huge introduced for organisations with more than eight teams. The framework remains simpler than SAFe but more prescriptive than pure "do Scrum at scale."
LeSS certification programme established. The framework gains adoption in European technology companies as an alternative to SAFe's complexity.
LeSS continues as a serious alternative to SAFe for organisations wanting genuine agility at scale without a heavyweight process layer. Its emphasis on organisational design aligns with DevOps and team topology thinking.