LeSS Requirements Model

LeSS (Large-Scale Scrum) is a framework for scaling agile development to large, complex projects involving multiple teams. LeSS provides a set of principles, rules, and practices for scaling agile development beyond the limits of a single team.

LeSS requirements model overview

LeSS requirements are managed through the “Requirement Area” model. The LeSS Requirement Area model is based on the following principles:

One Product Backlog

A single, prioritized Product Backlog manages all the requirements for the product, ensuring all teams work towards a common goal. The “One Product Backlog” also aligns development efforts with the business’s and end-users needs.

Team Backlog

While there is only one Product Backlog, each team working on the product may have its own Team Backlog. The Team Backlog is a subset of the overall Product Backlog, representing the work the team has committed to delivering during the current Sprint.

The Development Team manages the Team Backlog, deciding how to implement its requirements best. The Product Owner prioritizes the overall Product Backlog and collaborates with the Development Team to ensure the Team Backlog requirements align with the product goals.

While the Product Backlog and Team Backlogs are not separate from each other, they represent different levels of detail and abstraction. The Product Backlog represents the overall requirements for the product, while the Team Backlog represents the specific work that the team is committing to delivering during the current Sprint. By using a single Product Backlog and allowing each team to manage its own Team Backlog, LeSS helps ensure that development efforts focus on delivering the most important functionality first while allowing teams to work independently and efficiently.

Requirement Areas

LeSS Requirement Areas are used to group related requirements together to manage complexity and ensure that development efforts focus on delivering the most important functionality first.

A LeSS Requirement Area is a high-level grouping of requirements that are defined based on the business needs and priorities of the organization. A LeSS Requirement Area typically represents a significant area of functionality or capability, such as a subsystem, module, or business domain.

Examples of LeSS Requirement Areas might include:

• Authentication and Security: This Requirement Area might include requirements related to user authentication, data security, and access controls.
• Reporting and Analytics: This Requirement Area might include requirements related to generating reports, analyzing data, and visualizing information.
• Customer Management: This Requirement Area might include requirements for managing customer information, processing orders, and tracking customer interactions.

Using Requirement Areas helps to manage complexity and ensures that development efforts are aligned with the needs of the business and end-users.

Requirement Area Product Owners

Each LeSS Requirement Area is assigned a dedicated Product Owner responsible for managing the requirements within that area. The Product Owner is responsible for prioritizing the requirements within the Requirement Area, ensuring that they are well-defined and aligned with the overall business strategy, and communicating with the development team.

Shared Definition of Done

A shared Definition of Done is used to ensure that all requirements are completed to the same level of quality. The Definition of Done includes criteria for functionality, performance, usability, and other factors.

In LeSS, the Shared Definition of Done is similar to the Definition of Done in Scrum, but it is shared across all the teams working on the product. The Shared Definition of Done provides a common understanding of what constitutes a “done” increment of the product and includes criteria for functionality, performance, usability, and other factors. The Shared Definition of Done is typically defined collaboratively by the teams working on the product. It ensures that all the teams work towards a common goal and that development efforts align with the business’s and end-users’ needs.

LeSS Backlog Items

In LeSS, the Product Backlog is used to manage all the requirements for the product. The Product Backlog consists of several types of backlog items, including:

User Stories

User Stories are a common type of backlog item in agile development. They represent a single user need or requirement and clearly define what needs to be built to support that need.

Technical Stories

Technical Stories are backlog items that focus on technical work rather than user-facing functionality. They may include tasks such as refactoring code, optimizing performance, or upgrading infrastructure.

Bugs

Bugs are defects or issues that need to be fixed in the software. They are typically identified through testing or user feedback and are prioritized based on their severity and impact on the end users.

Spikes

Spikes are exploratory or research-based backlog items that are used to gather information or make a decision. They may include prototyping, proof-of-concept work, or researching new technologies.

Epics

Epics are large bodies of work that can be broken down into smaller, more manageable pieces. They typically span multiple teams and represent a significant investment of time and resources.

These backlog items are managed in a single, prioritized Product Backlog. The Product Owner ensures the backlog items are well-defined, prioritized, and aligned with the overall business strategy. The development team is responsible for delivering the backlog items in a timely and efficient manner while maintaining the desired level of quality.

LeSS Documentation Minimum Requirements

User Stories in LeSS

In LeSS, user stories concisely and understandably describe a single user’s need or requirement. The main elements of a user story in LeSS are:

• Title: The title of the user story should be concise. It should clearly describe the user need or requirement that the story addresses.
• User Role: The user role describes the type of user interacting with the system. It could be a customer, an employee, or any other type of user.
• User Need: The user need describes the specific need or requirement that the user has. It should be clear and concise and should focus on the specific functionality that the user requires.
• Acceptance Criteria: Acceptance criteria are a set of criteria that must be met for the user story to be considered complete. They provide a clear definition of what needs to be tested and ensure that software is developed to the desired level of quality.
• Business Value: Business value describes the user story’s value to the business or end-users. It should align with the overall business strategy and clearly understand why the user story is essential.
• Effort: Effort describes the effort required to complete the user story. It could be measured in story points or hours and is used to help prioritize work and manage capacity.
• Dependencies: Dependencies are factors that must be in place for the user story to be completed. They may include dependencies on other features or external systems.

By including these elements in a user story, the development team can ensure that they have a clear understanding of what needs to be built and why. The user story provides a way to manage development efforts and ensure that the software is developed to the desired level of quality. It also helps to ensure that development efforts align with the business’s and end-users needs.

Technical Stories in LeSS

In LeSS, a technical story is a backlog item focusing on technical work rather than user-facing functionality. Technical stories ensure that the software is developed to the desired quality level and that technical debt is managed effectively. The main elements of a technical story in LeSS are:

• Title: The title of the technical story should be concise. It should clearly describe the technical work that needs to be done.
• Description: The description of the technical story should provide a clear understanding of the technical work that needs to be done. It should be concise and easy to understand.
• Business Value: Business value describes the technical story’s value to the business or end-users. It should align with the overall business strategy and clearly state why the technical work is essential.
• Acceptance Criteria: Acceptance criteria are a set of criteria that must be met for the technical story to be considered complete. They provide a clear definition of what needs to be tested and ensure that the technical work is completed to the desired level of quality.
• Effort: Effort describes the effort required to complete the technical story. It could be measured in story points or hours and is used to help prioritize work and manage capacity.
• Dependencies: Dependencies are factors that must be in place for the technical story to be completed. They may include dependencies on other technical work or infrastructure.

By including these elements in a technical story, the development team can ensure that technical debt is managed effectively and that the software is developed to the desired level of quality. Technical stories provide a way to manage technical work and ensure it is completed promptly and efficiently. They also help to ensure that development efforts are aligned with the needs of the business and end-users.

Bug backlog item in LeSS

In LeSS, a bug is a backlog item representing a defect or error in the software that must be corrected. The main elements of a bug backlog item in LeSS are:

• Title: The title of the bug backlog item should be concise. It should clearly describe the bug or defect that needs to be corrected.
• Description: The description of the bug backlog item should provide a clear understanding of the problem that needs to be corrected. It should be concise and easy to understand.
• Reproduction Steps: Reproduction steps are required to reproduce the bug or defect. They should be clear and concise, enabling the development team to reproduce the bug or defect.
• Severity: Severity describes the impact of the bug or defect on the software. It helps to prioritize the bug backlog items and ensures that the most critical defects are addressed first.
• Priority: Priority describes the importance of the bug or defect. It helps to prioritize the bug backlog items and ensures that the most critical defects are addressed first.
• Acceptance Criteria: Acceptance criteria are a set of criteria that must be met for the bug or defect to be considered fixed. They clearly define what needs to be tested and ensure that the bug or defect is fixed to the desired level of quality.
• Effort: Effort describes the effort required to fix the bug or defect. It could be measured in story points or hours and is used to help prioritize work and manage capacity.

By including these elements in a bug backlog item, the development team can ensure that defects are managed effectively and that the software is developed to the desired level of quality. Bug backlog items provide a way to manage defects and ensure they are addressed promptly and efficiently. They also help to ensure that development efforts are aligned with the needs of the business and end-users.

Epics in LeSS

In LeSS, an epic is a large body of work that is too big to be completed in a single iteration or Sprint. Epics are used to group related user stories together and to provide a high-level view of the work that needs to be done. The main elements of an epic in LeSS are:

• Title: The title of the epic should be concise. It should provide a clear description of the overall theme or objective of the epic.
• Description: The description of the epic should provide a high-level overview of the work that needs to be done. It should be clear and concise and provide a general understanding of the overall scope of the epic.
• Business Value: Business value describes the epic’s value to the business or end-users. It should align with the overall business strategy and explain why the epic is essential.
• User Roles: User roles describe the types of users who will interact with the system or feature. It helps to consider different user needs when defining the requirements.
• User Stories: User stories are requirements related to the epic. They provide a more detailed view of the work that needs to be done and help ensure that development efforts focus on delivering the most important functionality first.
• Dependencies: Dependencies are factors that must be in place for the epic to be completed. They may include dependencies on other features, external systems, or infrastructure.
• Effort: Effort describes the effort required to complete the epic. It could be measured in story points or hours and is used to help prioritize work and manage capacity.

By including these elements in an epic, the development team can ensure they clearly understand the overall scope of the work that needs to be done. The epic provides a way to manage development efforts and ensure that the software is developed to the desired level of quality. It also helps to ensure that development efforts align with the business’s and end-users needs.

Conclusion

In conclusion, the LeSS requirements model effectively manages requirements in large, complex projects involving multiple teams. The model emphasizes using a single, prioritized Product Backlog that the Product Owner manages and the Team Backlogs that the Development Team manages. The use of Requirement Areas helps to group related requirements and manage complexity. Additionally, the Shared Definition of Done helps to ensure that all requirements are completed to the same level of quality.

The LeSS Backlog Items include User Stories, Technical Stories, Bugs, Spikes, and Epics. Each item has elements that help ensure clear communication and understanding among the development team. By using this model, development efforts are aligned with the needs of the business and end-users, and the software is developed to the desired level of quality.

Overall, the LeSS requirements model provides a comprehensive approach to managing requirements in large-scale agile projects, ensuring that all teams work towards a common goal and that development efforts focus on delivering the most important functionality first.

References

• Larman, C., & Vodde, B. (2016). Large-Scale Scrum: More with LeSS. Addison-Wesley Professional. Amazon
• Schwaber, K., & Sutherland, J. (2017). The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game. Scrum.org. Scrum.org
• LeSS.works. (n.d.). Requirement Areas. LeSS.works
• LeSS.works. (n.d.). Product Owner. LeSS.works
• LeSS.works. (n.d.). Definition of Done. LeSS.works
• LeSS.works. (n.d.). Product Backlog. LeSS.works
• Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional. Amazon
• Ambler, S. W. (2002). Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. Wiley. Amazon
• LeSS.works. (n.d.). LeSS Framework. LeSS.works