LeSS (Large-Scale Scrum)
Scrum principles scaled across many teams
LeSS (Large-Scale Scrum) applies Scrum principles to organisations with 2–8 teams working on the same product. Unlike SAFe, LeSS deliberately minimises process overhead — there is one Product Backlog, one Product Owner, and one Sprint for all teams simultaneously. LeSS Huge extends the framework to 8+ teams using Area Product Owners.
Developed by Craig Larman and Bas Vodde, documented in their book "Scaling Lean & Agile Development" (2008) and formalised at LeSS.works.
Use LeSS (Large-Scale Scrum) when
- ✓2–8 teams building the same product who need to synchronise without heavy governance
- ✓Organisations transitioning from component teams to cross-functional feature teams
- ✓You want Scrum principles at scale without SAFe's coordination layers
- ✓The product can be worked on by multiple teams pulling from a single prioritised backlog
Avoid it when
- ✗Organisations with strong siloed structures that resist team topology changes
- ✗Products with genuinely independent codebases that do not need synchronisation
- ✗Environments requiring SAFe's portfolio governance for compliance or funding reasons
Key Concepts
All teams share a single ordered backlog owned by one Product Owner — the key structural difference from SAFe.
A cross-team retrospective after every sprint to surface systemic issues that individual team retros cannot fix.
All teams plan together in the same room (or call) to coordinate dependencies and split backlog items.
Cross-functional teams that each deliver end-to-end customer features, as opposed to component teams.
An extension for 8+ teams that introduces Requirement Areas and Area Product Owners to manage scale.
A trade-show-style sprint review where each team demos at a station and stakeholders rotate between them.
How it works
All teams together with the Product Owner. Clarify backlog items and identify which team will own each.
Teams plan independently within their own spaces, breaking items into tasks and identifying cross-team dependencies.
Teams work in parallel on a shared codebase. Coordinate continuously through Scrum-of-Scrums or direct team contact.
Stakeholders tour team stations. Each team demos their increment. The Product Owner synthesises feedback.
Cross-team retrospective to identify systemic impediments. Followed by individual team retrospectives.
Tools that support LeSS (Large-Scale Scrum)
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Spreadsheet-familiar interface makes adoption easy for teams transitioning from Excel — minimal training needed for basic use
Extremely intuitive drag-and-drop Kanban interface — virtually zero learning curve, new users productive within minutes
Browser-based with no installation required — runs on any OS and enables instant sharing via URL, removing friction for cross-functional collaboration with PMs, engineers, and stakeholders
Frequently Asked Questions
LeSS is deliberately lean: it extends Scrum with minimal additions (one backlog, one PO, shared sprints). SAFe adds portfolio layers, ARTs, PI planning, and programme-level constructs. LeSS is better for teams that want agility at scale; SAFe is better for enterprises that need governance and compliance.
No, but LeSS works best when teams can easily coordinate. Distributed LeSS requires strong async practices, reliable video infrastructure for multi-team ceremonies, and a codebase with good modularity.
Basic LeSS has one Product Owner for all teams. LeSS Huge introduces Area Product Owners who own requirement areas, but they report to a single overall Product Owner who maintains backlog coherence.