One of the first things I discovered while attending Large-Scale Scrum (LeSS) training is that the term LeSS refers to both large-scale Scrum generally and the smaller LeSS framework. It turns out that there’s large scale and then there’s really large scale. Really large scale is where the second LeSS framework, LeSS Huge, comes along. […]
One of the first things I discovered while attending Large-Scale Scrum (LeSS) training is that the term LeSS refers to both large-scale Scrum generally and the smaller LeSS framework. It turns out that there’s large scale and then there’s really large scale. Really large scale is where the second LeSS framework, LeSS Huge, comes along.
To keep the smaller LeSS framework as simple as possible, Craig Larman and Bas Vodde, separated the few elements needed to scale beyond 8 teams into a separate framework and called it LeSS Huge.
By definition, LeSS applies to 2-8 teams and LeSS Huge to 8+ teams. Importantly, both include one Product Owner, one common Sprint across all teams, and one shippable increment.
One New Concept – Requirement Areas (RAs)
The LeSS Huge approach is to divide the product around major areas of customer concerns, which each become a Requirements Area (RA). less.works provides an example of a large securities product broken into several RAs, including trade processing, asset servicing, and new market onboarding.
RAs are dynamic and may grow or shrink over time to match the needs of the product. RAs are large themselves, typically including between 4-8 feature teams. All RAs follow the same Sprint cadence and try to integrate continuously across the entire product.
One New Artifact – Area Product Backlogs (APBs)
Adding the Requirement Area as an attribute in the Product Backlog creates an Area Product Backlog (APB) view for each RA. Each Product Backlog Item (PBI) belongs to one Area Backlog. Area Backlog Items will become more defined and will be prioritized and split, as needed, by the Area Product Owner.
One New Role – Area Product Owners (APOs)
At very large scale, think 50 teams and 200 PBIs per Sprint, it becomes near impossible for one Product Owner to grasp the whole product, manage the whole backlog, and balance all internal and outside inputs.
So along with establishing RAs, LeSS Huge introduces the role of the Area Product Owner (APO). The APO focuses on one Area Product Backlog and is usually a specialist in that area. To the feature teams in her RA, the APO essentially acts as the PO would in the smaller LeSS framework.
Meanwhile, there is still one designated Product Owner (PO) who is focused on overall product optimization across all RAs. It’s the PO’s responsibility to find and grow the APOs and to make decisions about creating, growing, or getting rid of RAs.
In summary, LeSS Huge attempts to add as few new elements as possible, while supporting ever larger scale. By introducing Requirement Areas and Area Product Owners, and running the smaller LeSS framework within each area, the LeSS Huge framework aims to support 8+ teams while still achieving the value and simplicity intended by Scrum.
I’ve coached a number of organizations, mostly Federal Government, where securing the application and its...
Scaling, like Agile itself, can become a target objective rather than the means to an...