Large Scale Scrum (LeSS)

Applying Scrum in a large-scale context

Large Scale Scrum (LeSS) focuses on how to apply principles and elements of Scrum in a large-scale context without overcomplicating processes or installing unnecessary bureaucracy. It is a ‘barely sufficient methodology’, revolving around many cross-functional, full-stack teams working together on their common goal and shared responsibility of delivering one shippable product – a complete end-to-end solution intended for real customers.

Key Purpose
& Core Principles

Large Scale Scrum
(LeSS)

Less is more

The key purpose of LeSS is to have many Scrum teams working together with as few processes and procedures as possible. As the name implies, the goal is to make the way of working and scaling as simple as possible.

Like SAFe, LeSS has defined a number of principles to guide the work within the framework:

  1. Large-Scale Scrum is Scrum
  2. Empirical process control
  3. Transparency
  4. More with less
  5. Whole-product focus
  6. Customer-centric
  7. Continuous improvement towards perfection
  8. Systems thinking
  9. Lean thinking
  10. Queuing theory

An Introduction to Key Elements

Roles

Keeping it simple, LeSS revolves around two main roles – Product Owner working with 2-8 teams and Scrum Masters working with 1-3 teams – with role descriptions stemming from standard scrum. The exception is that LeSS prefers to move the responsibility of refining the product backlog items from the Product Owner to the teams, which must be cross-functional and contain a combination of business domain knowledge and technical excellence. This means that a key prerequisite for success is that the teams are empowered to be able to directly interact with the customers.

All teams share a unified product backlog which they work on in synchronized sprints lasting 1-4 weeks. At the end of the sprint, the teams jointly deliver a product increment.

Ceremonies

In terms of ceremonies, LeSS places key emphasis on planning, product backlog refinement, and the sprint review and retrospective.

Planning is split into two parts; the first part where selected team representatives meet with the Product Owner and commit to selected product backlog items as well as discuss cross-team collaboration during the coming sprint. In the second part, the teams gather separately to plan the sprint and refine the sprint backlog.

Product Backlog Refinement is continuously done throughout the sprint in order to ensure that the product backlog items are ready for sprint planning, e.g. by splitting big items, detailing items, and estimating effort.

The end of sprint focuses on 3 activities: 1) The sprint review, where the team and customers review the sprint outcome together, 2) the retrospective, where improvement areas are identified and successes are celebrated in each team, and 3) the overall retrospective, where all teams, Product Owners, and Scrum Masters get together to inspect and adapt practices to gain improved efficiency. 

In doubt which agile framework to choose?​