LeSS

LeSS on one screen

Here is the whole framework first. LeSS is defined by a short list of rules; everything else its authors publish is advice. The first table restates every rule of LeSS Basic — the version for two to eight teams — in plain words, with what it replaces in a typical multi-team setup and what breaks when it is skipped. The last row is the one rule LeSS Huge adds. The second table lists every event in the order a SprintSprinta fixed-length work cycleA fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.Full article →All terms runs them.

Scaling by subtraction

Start with what usually happens when a product outgrows one team. A second team appears, then a third. Someone notices that three Product Owners are now prioritising against each other, so a coordinator is hired above them. Integration keeps slipping, so an integration team is created. Six months later there is a programme manager, a release manager, a steering committee, and a set of hand-offs between them — and delivery is slower than it was with one team.

LeSS treats that whole chain as the disease, not the cure. Its answer is to scale Scrum by adding as little as possible: one Product OwnerProduct Ownerowns what gets builtThe one person accountable for what the team builds and in what order. The authority is real — a Product Owner who has to get every decision approved elsewhere is a messenger, and the role stops working.Full article →All terms for the entire product, one Product BacklogBacklogthe ordered list of what is leftThe ordered list of everything that might be built, with the most valuable at the top. Ordered is the operative word: a backlog where everything is equally important is a wish list, and it makes no decision easier.Full article →All terms, one Sprint that every team shares, and one integrated IncrementIncrementthe working result of a sprintEverything finished so far, taken together and actually working — not the pile of tickets closed this sprint. The test is whether it could be released today, even if the decision is not to.Full article →All terms at the end of it. No new role sits above the team. No programme layer sits between the teams and the customer.

The framework’s own word for this is descaling. Instead of adding machinery to manage coordination, it removes the organisational boundaries that created the need for coordination in the first place. Every boundary between two groups is a hand-off, and every hand-off is a queue, a translation and a place where priorities can disagree. Remove the boundary and the coordination it demanded goes with it.

The first decision: what counts as the product

LeSS asks one question before any other, and most adoptions skip it: what is the product? The answer decides how many Product Owners and backlogs you end up with. Define it narrowly and there are many products, each with its own owner, and every change that crosses two of them becomes a negotiation. Define it broadly and the same change is one item in one backlog, ordered by one person.

LeSS’s guidance is to define the product as broadly as is practical and as close to the customer as possible, then ask whether one person can own it. When the answer is no, that is where LeSS Huge begins — it is not a reason to cut the product narrower again.

The fork in scaling: subtract or add

This is the clearest fork in scaling. LeSS asks the organisation to change so the framework fits; SAFeSAFeScaled Agile Framework — a framework for running many agile teams as oneThe Scaled Agile Framework: roles, events and practices for coordinating dozens of agile teams, built around the Agile Release Train — five to twelve teams that plan together every eight to twelve weeks. It is the most prescriptive and the most widely adopted scaling framework, which is also why it can be installed without changing who makes the decisions.Full article →All terms fits itself to the organisation. LeSS produces the better outcome where leadership genuinely commits to the reorganisation, and fails outright where it does not — there is no half-LeSS that still works, because the rules it drops are the ones holding the rest up. Nexus sits between the two: it shares the single Product Owner and backlog, adds one accountability for integration, and asks for no reorganisation at all — which makes it the smaller first step, and LeSS the deeper one.

Feature teams, and what LeSS removes

A component team owns one technical part of the system — the front end, the payments service, the database. A feature team owns a customer-visible piece of the product end to end, and works in every component that piece touches. LeSS requires most teams to be feature teams. It is the rule adoptions most often claim to follow and least often do.

The difference is arithmetic, not style. With component teams, a feature that touches three components is split into three pieces, each waiting in a different team’s queue behind that team’s other work. The feature is done when the slowest piece lands, and the pieces meet for the first time at integration. With a feature team, the same feature waits in one queue and is integrated by the people who wrote all of it.

The cost is real and should be planned for rather than denied. A feature team has to work in code it did not write, and for the first months it will be slower in unfamiliar components than the specialists were. LeSS’s answers are people-based: a component mentor who knows a component well, teaches the teams working in it and reviews their changes without owning a queue; communities of practice for a shared skill; pairing; and a shared codebase that everyone is allowed to change. The specialists do not disappear — they stop being a queue.

What LeSS keeps, and what it removes

The roles in LeSS are the Scrum roles and nothing else. One Product Owner owns the ordering of the whole Product Backlog, and teams talk to customers and users directly rather than through business analysts. The teams are feature teams — cross-functionalcross-functionalholding every skill the work needsSaid of a team that holds every skill needed to take its work from idea to production — design, development, testing, operations — so it does not wait for other departments to finish their part. The trade-off is depth: specialists spread across teams need another structure, such as a chapter or a guild, to keep their craft consistent.Full article →All terms, long-lived, and ten or fewer people each, as the Scrum Guide has it. A Scrum MasterScrum Masterremoves what blocks the teamThe person responsible for the process working, not for the work getting done. They remove blockers and protect the team from interruption — they are not the manager of the team, and treating the role as management is the usual way it fails.Full article →All terms serves one to three teams full time — the "full time" is a rule, because a part-time Scrum Master reliably reverts to being a coordinator.

The removals are the harder half. There is no project manager, no programme manager, no team lead assigning work, no separate architecture group deciding for the teams, no analysis or testing department, no PMOPMOProject Management Office — the office that sets project standardsA unit that sets project-management standards across an organisation, collects reporting from its projects and sometimes employs the project managers. Its value depends on which of those it does: a PMO that only gathers status reports adds a layer without adding a decision.All terms between the Product Owner and the customer. Existing managers do not have to disappear, and the rules call them optional rather than forbidden. But their job changes from directing work to improving the system the work runs through: going to see how the teams actually work, teaching, removing the impediments no team can remove, and growing people.

Undone work and the Undone Department

LeSS names a gap most organisations have and few measure. On one side is everything that must happen before the product can actually ship — performance testing, security review, documentation, regulatory evidence, the release itself. On the other is the team’s Definition of DoneDefinition of Donewhat "finished" means hereThe checklist a piece of work must pass before anyone may call it done — tested, reviewed, documented, deployed, whatever the team agreed. Its value is that "done" stops being a matter of opinion in a status meeting.Full article →All terms. Whatever lies between the two is undone work, and whoever does it after the Sprint is what LeSS calls the Undone Department: a release team, a test group, a hardening phase.

The rule is not to abolish that department on day one. It is to widen the Definition of Done a step at a time, moving one activity into the Sprint whenever the teams can take it on, until the department has nothing left to do. The Scrum page draws the same gap and why deferring it is the expensive choice; LeSS adds that at scale the undone work of eight teams arrives at once.

Ten principles, and three layers of guidance

LeSS is deliberately thin on rules and thick on principles — the rules tell you what the structure must be, the principles tell you how to decide everything the rules leave open. There are ten of them, and they are not decoration: when a LeSS adoption goes wrong, it is almost always because a decision was made against one of these while the rules were technically still followed.

The principles sit under three layers of published content with very different authority, and knowing which layer a statement belongs to is the difference between adopting the framework and copying its surface.

• Rules — mandatory

  The minimal definition of LeSS, the first table on this page. Break a rule and you are no longer doing LeSS — which is a legitimate choice, but say so honestly.

• Guides — tested advice

  Practices that have worked in many adoptions: how to run Sprint Planning One, how to form feature teams, how a Product Owner works with many teams. Strongly recommended, not required.

• Experiments — try and see

  Things that worked somewhere and failed elsewhere, published with both outcomes. The books deliberately list experiments to avoid alongside promising ones.

This layering is why LeSS documentation is thin where SAFe’s is thick. LeSS claims that beyond a small set of structural rules the right practice depends on the organisation, so publishing a detailed prescription would be dishonest. The trade-off is real: LeSS gives you less to copy and therefore demands more judgement from whoever leads the adoption.

The events, one by one

All teams run one shared Sprint of the same length, starting and ending on the same day. The events are the Scrum events with a defined answer to one question: what happens when eight teams need to do this at once?

Sprint Planning One and Two

Sprint Planning One is short and shared. The Product Owner brings the top of the backlog, and members of every team — all of them, or representatives of each when the room would be too big — decide which team takes which items. The choice is tentative on purpose, and its second output matters as much as the first: spotting items where two teams should work closely, before anyone has written a line.

Sprint Planning Two follows straight after, and each team plans how it will build its items. Teams that took closely related items plan in the same room, in what LeSS calls a multi-team Sprint Planning Two, so that a shared design decision is made once rather than twice.

Three kinds of refinement

• Overall refinement

  Short, once a Sprint: the Product Owner and team representatives look at the backlog as a whole, split big items and decide which teams will refine what.

• Multi-team refinement

  Two or more teams refine related items together, in one room. It spreads knowledge of an area across teams and keeps open the choice of which one takes the work.

• Single-team refinement

  The ordinary Scrum activity, for items one team is likely to take. The default in Scrum, and the exception in LeSS whenever items overlap.

Daily Scrum, and coordination between events

Each team keeps its own daily meeting and its own Sprint Backlog. There is no daily meeting of all teams, and no standing coordination meeting above them. Coordination between the events is left informal on purpose — LeSS calls the default "just talk" — and the guides for it are about people, not meetings.

Sprint Review and the two retrospectives

There is one Sprint Review for the whole product, and it is a review with customers and users in the room, not a demo to them. Its output is a changed backlog, not applause.

Each team then holds its own retrospective on what it can improve by itself. The Overall RetrospectiveRetrospectivethe meeting that changes the processThe regular meeting where a team examines how it works and changes one thing. A retrospective that ends without a named change someone owns is a complaint session, and teams stop attending it for good reason.Full article →All terms comes after them — many groups hold it early in the next Sprint — and it works on the system the teams sit in: the build, the release, the way work arrives, the rules of the organisation. The Product Owner, the Scrum Masters, team representatives and managers attend. It is the one event managers are expected at, because most of what it finds is theirs to fix.

LeSS Huge: Requirement Areas

• LeSS Basic — 2 to 8 teams

  One Product Owner can hold the whole backlog in their head. All teams share one Sprint Review and one Overall Retrospective. Nothing beyond Scrum is added — this is the framework in its intended form.

• LeSS Huge — 8+ teams

  The backlog is divided into Requirement Areas, each with an Area Product Owner and four to eight teams. The single Product Owner remains, now ordering across areas rather than across items.

A Requirement Area is a major area of customer concern, and the rule that makes or breaks LeSS Huge is how you cut them. Areas are cut by what the customer needs, never by technical component. An area named "checkout" is correct. An area named "database layer" recreates exactly the hand-off LeSS exists to remove, and it will produce component teams with a new label within two Sprints.

Each area needs at least four teams. That floor is there on purpose: an area of one or two teams is a department wearing the word "area", and it starts behaving like a separate product with its own priorities. The ceiling of eight is Basic LeSS’s own limit, because inside its area an Area Product Owner works with the teams exactly as the Product Owner does in LeSS Basic.

There is still one Product Backlog. Each item carries the area it belongs to, and an area backlog is simply a view of the one backlog filtered to that area — not a second list someone maintains. The Product Owner and the Area Product Owners work as one product owner team and meet before and after each Sprint, and the Product Owner’s real lever is capacity: moving a team from one area to another when the balance of customer value shifts.

Areas are expected to change as the product does — they are a current view of demand, not an org chart to defend. And LeSS Huge is not switched on in one step. The rules call its adoption evolutionary: one area at a time, each run as LeSS Basic until it works, over months or years.

Adopting LeSS, and what four adoptions show

A LeSS adoption is an organisational design change wearing a process name. In practice it means dissolving component teams, removing a layer of middle management and giving one person authority that was previously spread across a steering group. LeSS is unusually direct about this, and its adoption guidance comes down to three principles.

• Deep and narrow over broad and shallow

  Change one product group completely rather than every group a little. A group that changed all the way is something the rest of the organisation can go and see.

• Top-down and bottom-up

  The structure can only be changed by the people who own it, and the work can only be changed by the people who do it. Either half alone stalls.

• Volunteering

  People choose to join the first product group, and teams largely form themselves. Assigned volunteers are the first thing the cases below report going wrong.

The technical precondition is the one most often underestimated. One integrated Increment per Sprint across eight teams is impossible without continuous integration into a shared branch, a single Definition of Done every team meets, and an automated test suite that runs in minutes rather than overnight. Organisations that adopt the LeSS structure without that engineering base end up with several Scrum teams sharing a backlog and an integration crunch at the end of every Sprint.

Most published LeSS cases are written by the coaches who led them, on the framework’s own site. That makes them selective. What makes the four below worth reading is that three of them report what went wrong in detail.

Where it degrades

Here is the diagnostic question for any LeSS adoption: who decides the order of the next ten items in the backlog? If the answer is one person, LeSS is working. If it is a meeting of area leads, a steering committee, or "it depends on the team", the structure LeSS removed has come back under another name.

Craig Larman, one of LeSS’s two authors, predicted how that happens in five short "laws of organizational behavior", paraphrased here. Organisations are implicitly built to protect the existing manager and specialist positions. So any change is reduced to new names for the old roles. Anyone who resists that is called purist or theoretical. Displaced managers and specialists become coaches of the change, and declare it done. And in large organisations, culture follows structure — which is why LeSS changes the structure first.

The honest limit sits in the same place. LeSS solves coordination by removing the structure that causes it, and it has no answer for an organisation unwilling to remove it: there is no reduced version that still works. The BMW case adds a second limit — changing the structure does not change the rewards, career paths and appraisals around it, and those pull the structure back. And where the product cannot be integrated every Sprint at all — hardware with long lead times, a regulator’s release cycle — the one-Increment rule becomes a direction rather than a fact, and LeSS says so, which is honest but leaves you to decide how much undone work you can live with.

• Several Product Owners appearing "for practical reasons", which restores the layer LeSS removed.
• Component teams renamed feature teams, with every feature still needing three of them.
• Requirement Areas cut by technical component, or holding two or three teams each.
• Nine areas launched before the first one works, each inheriting its problems.
• Teams integrating only at the end of the Sprint, so "one Increment" is an assembly scramble.
• A Definition of Done that never grows, so the Undone Department becomes permanent.
• A part-time Scrum Master shared across five teams, who becomes a meeting coordinator instead of changing the system.
• The removed management level quietly revived as "team leads", with the old appraisal system intact.
• Skipping the Overall Retrospective, which is where the cross-team and organisational impediments were supposed to be raised.

When to use it

Related pages

• ManagementSAFeSAFe, the Scaled Agile Framework, is a set of roles, events and practices for running dozens of agile teams on one shared planning rhythm. It is the most prescriptive of the scaling frameworks and by far the most adopted in large enterprises, precisely because it gives an existing management structure a defined place to stand. The page opens with the whole framework on one screen — every event at every level with its cadence, and who sits at each level — then covers the Agile Release Train and the Planning Interval, the four configurations and the adoption roadmap, PI Planning and Inspect & Adapt, how SAFe measures itself and how each measure is gamed, its values and ten principles, what the independent evidence shows, and where it degrades.
• ManagementNexusNexus is Scrum.org’s framework for three to nine Scrum teams building one product, and it adds exactly one accountability to Scrum: a Nexus Integration Team. Its premise is that at this scale integration, not planning, is what breaks first. The page opens with every Nexus element on one screen — each event and what it does to its Scrum counterpart, and the three artefacts with their commitments — then covers why the one addition, who is really on the Integration Team, each event as the 2021 Guide defines it and what changed from 2018, how to find and remove dependencies, how Nexus compares with LeSS, SAFe and Scrum@Scale, what the evidence shows and where it degrades.
• ManagementOrganisational StructuresAn organisational structure is how a company groups its work into units and who reports to whom — which decides who can give a project people, money and decisions. Line, functional and matrix are not management methodologies like Scrum or Kanban. They are the shape of the organisation a methodology has to run inside, and they set how much authority the person leading a project really has. The page opens with every common structure side by side and five questions that tell you which one you are in, then covers the two questions behind every structure, the classic hierarchies, the matrix and its nine known failure modes, project and product teams, Conway’s law, companies that tried to do without managers, and where restructuring turns into theatre.