How to Use Requirement, Feature, PBI, and Task Hierarchies Effectively

When an initiative spans multiple releases, organizing its backlog can become surprisingly difficult.

Imagine a larger product capability that starts with an MVP and is extended release by release. Given an Azure DevOps hierarchy such as:

Requirement
└── Feature
    └── PBI
        └── Task

where should the boundaries be drawn?

Should the entire initiative live under a single Requirement? Or should each release or implementation phase receive its own Requirement?

The answer depends primarily on the semantic meaning assigned to each hierarchy level.

The Fundamental Question: What Does a Requirement Represent?

Consider an initiative for adding Object-Based Storage (OBS) recording.

One possible structure uses a single Requirement:

Requirement: Object-Based Storage Recording

├── Feature: OBS target configuration
├── Feature: Continuous recording
├── Feature: Playback support
├── Feature: Audio recording
├── Feature: Alarm/schedule recording
├── Feature: Timeline indicators
├── Feature: Export recordings
└── Feature: Gateway for legacy cameras

Another approach creates Requirements for individual phases:

Requirement: OBS Recording MVP
├── Feature: OBS target configuration
├── Feature: Continuous recording
└── Feature: Playback support

Requirement: OBS Recording Enhancements
├── Feature: Audio recording
├── Feature: Alarm/schedule recording
└── Feature: Timeline indicators

Requirement: OBS Recording Advanced Capabilities
├── Feature: Export recordings
└── Feature: Gateway for legacy cameras

Both structures are technically possible. But they assign very different meanings to the Requirement level.

Option A: One Requirement for the Entire Initiative

With this model, a Requirement represents a broad product theme or strategic initiative.

For example:

Requirement: Object-Based Storage Recording

Everything related to OBS recording is grouped underneath it.

This provides several advantages:

• one clear umbrella for the initiative,
• straightforward high-level traceability,
• related functionality remains grouped together,
• and the Requirement clearly represents the overall product capability.

The main disadvantage is its potentially long lifetime.

An initiative such as MQTT integration, cloud readiness, or object-based storage might evolve over several product versions. Consequently, its Requirement could remain active for years.

Progress at the Requirement level can therefore become difficult to interpret. A Requirement might be 80 percent complete, but what does that actually mean if additional functionality can continuously be added?

Option B: Requirements per Phase

An alternative is to use Requirements as delivery increments:

Requirement: OBS Recording MVP

Requirement: OBS Recording Enhancements

Requirement: OBS Recording Advanced Capabilities

This creates much clearer boundaries around releases or development phases.

Individual Requirements can be completed and closed, roadmap communication becomes easier, and progress reporting has an obvious endpoint.

However, there is a trade-off.

The Requirement level no longer represents the overall theme. Instead, it represents a particular delivery phase.

The conceptual relationship between the different Requirements must then be expressed elsewhere through naming conventions, links, tags, or an additional hierarchy level.

Let the Definition of the Hierarchy Decide

The choice becomes much clearer when there is an explicit internal definition for the Requirement level.

Suppose the guidance defines its purpose as:

Define theme or epic, form a brace.

This gives the Requirement level a specific semantic meaning.

A Requirement is intended to represent a theme, epic, problem domain, or conceptual bracket around related functionality.

The hierarchy can therefore be interpreted as:

Under this definition, using Requirements for individual releases would mix two different concepts: thematic organization and delivery planning.

The Requirement as a Brace

The phrase “form a brace” is particularly useful for understanding the intended structure.

The Requirement creates a logical bracket around Features belonging to the same broader capability.

For example:

Requirement: Object-Based Storage Recording

├── Feature: Add OBS storage target
├── Feature: Continuous recording to OBS
├── Feature: Playback from OBS
├── Feature: Recording with audio
├── Feature: Alarm-based recording
├── Feature: Timeline indicators
└── Feature: Export recordings

The Requirement answers:

What broader product capability are we addressing?

The Features answer:

Which independently deliverable capabilities contribute to it?

That distinction creates a stable and understandable hierarchy.

Features Should Represent Deliverable Increments

If the Requirement represents the long-lived theme, release-specific slicing can happen at the Feature level.

For example:

Requirement: Object-Based Storage Recording

├── Feature: OBS – MVP Recording
├── Feature: OBS – Recording with Audio
├── Feature: OBS – Alarm/Schedule Recording
├── Feature: OBS – Playback Improvements
├── Feature: OBS – Export
└── Feature: OBS – Legacy Camera Gateway

Features can then be assigned to different releases without changing the semantic meaning of the Requirement.

This provides both views:

Requirement
    ↓
Strategic / thematic grouping

Feature
    ↓
Deliverable capability

PBI
    ↓
Implementable behavior

Task
    ↓
Engineering work

The hierarchy describes decomposition, while release planning determines when those pieces are delivered.

These are related concerns, but they should not necessarily be represented by the same structural mechanism.

Making Release Phases Visible

Sometimes it is still useful to make implementation phases immediately visible in the backlog.

One pragmatic approach is to include the phase in Feature names:

Requirement: Object-Based Storage Recording

├── Feature: OBS – Phase 1 – MVP Recording
├── Feature: OBS – Phase 2 – Audio Recording
├── Feature: OBS – Phase 2 – Alarm Recording
├── Feature: OBS – Phase 3 – Advanced Playback
└── Feature: OBS – Phase 3 – Export

Alternatively, release information can be represented through Azure DevOps fields such as iteration paths, target versions, tags, or other project-specific metadata.

The important principle is that release information should not redefine the purpose of the hierarchy.

Another Example: MQTT Integration

The same principle applies to other long-running initiatives.

Instead of creating:

Requirement: MQTT MVP
Requirement: MQTT Phase 2
Requirement: MQTT Advanced Features

a theme-oriented hierarchy could be:

Requirement: MQTT Integration

├── Feature: MQTT communication with ADAM devices
├── Feature: MQTT support for generic devices
├── Feature: MQTT rule engine
└── Feature: MQTT device templates

Individual Features can be delivered in different releases while the Requirement remains the stable thematic anchor.

Long-Lived Requirements Are Not Necessarily a Problem

One argument against this model is that the Requirement may remain open for a long time.

That is true—but it is only a problem if Requirements are expected to behave like normal delivery items.

If a Requirement represents a theme or epic, its lifetime naturally differs from that of a Feature or PBI.

A long-lived Requirement can be perfectly reasonable when its primary purpose is to provide structure and traceability.

In fact, trying to force every Requirement into a release-sized lifecycle can undermine its role as the stable bracket around the initiative.

Avoid Mixing Hierarchy and Roadmap

A useful distinction is:

Hierarchy describes how functionality belongs together. Roadmap information describes when functionality is delivered.

Using the hierarchy for both purposes can produce confusing structures.

For example, splitting Requirements solely because a new release starts means that the same conceptual initiative suddenly has several unrelated roots.

Keeping the Requirement stable while slicing Features according to deliverable capabilities preserves the conceptual structure without sacrificing release planning.

Recommended Structure

If the Requirement level is explicitly defined as “theme or epic, form a brace,” the most consistent model is:

Requirement: Strategic initiative / theme
│
├── Feature: Deliverable capability A
│   ├── PBI: Implementable behavior
│   │   ├── Task: Engineering activity
│   │   └── Task: Engineering activity
│   └── PBI: Implementable behavior
│
├── Feature: Deliverable capability B
│   └── ...
│
└── Feature: Deliverable capability C
    └── ...

This gives each level a distinct responsibility:

• Requirement → Why / broader theme
• Feature → What capability is delivered
• PBI → What behavior is implemented
• Task → How the implementation is performed

Release and phase information can then be applied to the Features and PBIs without changing the meaning of the Requirement.

Conclusion

There is no universally correct Azure DevOps hierarchy independent of the conventions used by a team. The important part is that every hierarchy level has a clearly defined and consistently applied purpose.

If a Requirement is defined internally as something that “defines a theme or epic and forms a brace,” then one Requirement for the overall initiative is the most consistent approach.

The resulting principle is simple:

Use Requirements to structure the product domain and Features to slice the deliverable capabilities.

For initiatives spanning multiple releases, this keeps the Requirement stable while Features provide the smaller increments needed for roadmap planning, implementation, testing, and delivery.

In short:

Requirement = theme
Feature     = deliverable capability
PBI         = implementable behavior
Task        = engineering activity

Keeping those semantics stable makes the backlog easier to navigate, explain, and maintain—even when an initiative evolves over several product generations.