A Requirement is a condition or capability that must be met by a system or component to satisfy a contract, standard, specification, or other form of request.

Backlogs are simple collections of requirements that are prioritized by a relevant customer and split into “must haves” and “would like to haves”. Backlogs can contain a mix of functional and non-functional requirements as well as other objectives. They are typically used at team boundaries to manage incoming work. Backlogs can be useful for a variety of delivery methods including waterfall teams (not recommended), agile iterative teams and continuous flow teams.

Backlogs are a prioritised list of things to do which add business value. Backlogs are simply queues of work and as such are useful at any organizational or team boundary as a way of capturing and (re-)prioritizing incoming work. For overloaded teams they also provide a useful visual mechanism for displaying the amount of manageable vs. unmanageable work. From a systemic point of view, establishing pull in an organization can be realized in terms of the division between “must haves” and “nice to haves” in a backlog. Backlogs will often contain other non-requirement pieces of work such as Bugs/Changes or overhead activities.

There are two Backlogs described in Holistic Software Development the Product Backlog and the Programme Backlog, however in a Project with a team of teams structure each team may have a Team Backlog which may be a subset of a higher level backlog or a refinement of some of the higher level elements. The collection of Portfolio Requests and even the collection of Customer Requests can also be considered as a Backlog although the term is less common amongst business managers.

Working with Backlogs

Backlogs aren’t just a collection of requirements, they’re also a statement of scope. The “must haves” in a backlog are used to represent 100% of the current committed scope. Although this will naturally change over time the understanding of scope means that we can measure progress by the amount of the backlog that has been completed to a given Definition of Done.  As a result, if we measure completion over time, then we can extrapolate forward to indicate when the must-haves will be complete.
The “would like to haves” become a wish list for the currently committed scope. This means that Backlogs are theoretically endless making multi Release backlogs a little more difficult to work with. Instead of over complicated prioritization schemes we recommend that items in a backlog are first tagged by Release. The immediate Release is the only one that will be further worked with, everything else can be filtered away until we’re almost done with the current Release.
Within the current Release we recommend ordering Backlog items, with Customer involvement and agreement, in terms of a simple prioritization scheme. Either High, Medium, Low or forced-ranking are acceptable. We recommend considering the bottom “chunk” as “on the bubble” meaning that the lowest n-items (as agreed between teams and their Product Customer) are at risk. This is an honest reflection of the realities of software development.
Often in development backlogs Story Points are used as an indicator of the relative size of backlog items to further refine this extrapolation.

Story Points are an abstract, arbitrary number associated with User Stories that indicates the relative effort (not complexity) required to complete the story development.

To manage activities that are necessary but not directly related to delivering business value to the customer we recommend the use of Objectives.

Objectives represent non-requirement activities that must be done to enable successful delivery.

Objectives can be used to represent overhead, setup and team improvement activities on a backlog. These concerns should not be considered as user stories as they add no direct value to a consumer. Objectives, therefore, should not contribute story points to team velocity (for agile/iterative teams) as they are not part of the product scope and will be inconsistent in terms of effort, therefore extrapolation of their completion is meaningless. Instead Objectives are best thought of as overhead. Explicit representation of overhead vs. requirements means that teams can be transparent in discussions with Product Customers regarding the necessity of overhead activities and trade them in/out against requirements.


Non-Functional requirements can be incorporated in Backlogs either as embedded NFR critieria on requirements or as cross-cutting NFRs, often represented as Integration Scenarios.

Non-Functional Requirements are requirements specifying general characteristics of a system, not its specific functional behaviour. Typical categories of non-functional requirements are Usability, Reliability, Performance, Supportability, Security, Scalability, Quality etc.


Bugs and Changes often need prioritising alongside requirements and so are often present on Backlogs.

A Problem is an issue negatively affecting the relationship between a User/Stakeholder and the Product. Problems are often represented as “Bugs” or “Changes”

Backlog as WBS (Work Breakdown Structure)

A traditional approach to planning is the creation of work breakdown structures (WBS). A WBS decomposes activities into smaller and smaller units, with dependencies between them creating critical paths for planning. Although a WBS is a useful way of understanding what might need to be done it encourages false accuracy across chains of WBS items and removes responsibility for problem solving from team members into the hands of an elitist planner or Project Manager.

A common dysfunction we have observed in teams adopting Backlogs and User Stories is to adopt the terminology but actually still do WBS planning using these terms. A symptom of this approach is a backlog that is comprised of a hierarchical structure of “Epics” with child “Stories” (sometimes multiple levels of each) and finally child “tasks”. This obscures the purpose and clarity of a genuine backlog and also makes the classic WBS harder to see devaluing both approaches.

Product Backlog

A Product Backlog is a collection of requirements which are prioritized and split into “must have” and “wish list” items. Backlogs also include non-functional requirements either as items in the list or as cross-cutting requirements related to the functional requirements in the list.

A Product Backlog is made up of User Stories and associated Non-Functional Requirements for a Product. Sometimes a Product Backlog may be further sub-divided into Team Backlogs. The elements in a Product backlog are the requirements source for Planning and System Architecture.

Items in a Product Backlog typically trace to a Scoping Diagram item or a Programme Backlog item (e.g. Feature or Integration Scenario).

Programme Backlog

A Programme Backlog is a collection of requirements which are prioritized and split into “must have” and “wish list” items. Backlogs also include non-functional requirements either, as items in the list, or as cross-cutting requirements related to the functional requirements in the list.

A Programme Backlog is made up of Integration Scenarios, Features and associated Non-Functional Requirements for a related set of projects that together deliver some Business Value. Programme Backlogs are used to prioritise high level features and define acceptance critera prior to just-in-time decomposition into finer grained requirements in Product Backlogs. The Programme Backlog serves as the requirement source for Programme Planning and Solution Architecture. Sometimes a Programme Backlog may also contain Scoping Use Cases although we recommend using Integration Scenarios.

These elements frequently exist outside of a Programme Backlog, where a Programme isn’t being used to coordinate multiple products.