Where Does the MVP Belong in an Azure DevOps Backlog Hierarchy?

When a new product capability is implemented incrementally, a common question arises during backlog refinement:

At which backlog level should the MVP live?

Consider an Azure DevOps hierarchy consisting of:

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

The capability may evolve over several releases. The first release provides a Minimum Viable Product (MVP), while later releases gradually extend it with additional functionality.

The question is therefore not only how to represent the MVP, but also how to organize the complete capability over its lifetime. This was the central question discussed in the original notes.

The Recommended Mapping

A useful and consistent interpretation of the hierarchy is:

Backlog Level	Purpose
Requirement	Overall capability, business need, theme, or initiative
Feature	Deliverable increment such as the MVP or a later extension
PBI	Individual user-facing behavior or smaller functional slice
Task	Concrete development, testing, or engineering activity

Under this model, the MVP belongs primarily at the Feature level.

The Requirement represents the broader capability that remains relevant throughout multiple releases, while the MVP is the first meaningful implementation of that capability.

This is also the common conclusion across the different perspectives collected in the original discussion: the MVP is generally represented as a Feature containing the PBIs necessary to create the first valuable product increment.

Requirement: The Stable Capability

The Requirement should describe the overall business or product capability rather than the first release of it.

For example:

Requirement: Automated Customer Onboarding

This Requirement can remain stable while the implementation evolves over time.

Another example could be:

Requirement: Object-Based Storage Recording

The Requirement describes what broader capability the product should provide, without tying it to a particular implementation phase or release.

This creates a stable traceability anchor throughout the lifecycle of the initiative.

Feature: The MVP

The first Feature underneath the Requirement can represent the MVP:

Requirement: Automated Customer Onboarding

└── Feature: Customer Onboarding MVP

The MVP Feature contains the smallest cohesive set of functionality that makes the new capability useful.

For example:

Requirement: Automated Customer Onboarding

└── Feature: Customer Onboarding MVP
    ├── PBI: Create an account using an email address
    ├── PBI: Upload basic documents
    ├── PBI: Review onboarding status
    └── PBI: Complete basic onboarding

This reflects the idea that an MVP is not usually one tiny user story. It is a collection of smaller behaviors that together produce something usable.

The original comparison therefore treats the Feature level as the natural place for the MVP, with PBIs providing the smaller implementation slices beneath it.

PBIs: Slice the MVP into Valuable Behaviors

The Feature should not become the unit developers work on directly.

Instead, it should be broken down into PBIs.

For example:

Feature: Customer Onboarding MVP

├── PBI: User can create an account
├── PBI: User can upload documents
├── PBI: User can see the onboarding status
└── PBI: User can submit the onboarding request

Each PBI should ideally describe a small, testable, and independently understandable piece of behavior.

For the MVP, the PBIs should contain only the functionality that is genuinely required to deliver the minimal valuable solution. Later improvements should not be included simply because they belong to the same long-term capability.

The source material makes the same distinction: PBIs represent the individual units of functionality that compose the Feature, while Tasks provide an even finer-grained engineering breakdown.

Tasks: Describe the Engineering Work

Tasks belong underneath PBIs and represent implementation activities.

For example:

PBI: User can create an account

├── Task: Implement account creation API
├── Task: Add database persistence
├── Task: Implement account creation UI
├── Task: Add automated tests
└── Task: Update documentation

Tasks answer a different question than PBIs.

A PBI describes what behavior should exist.

A Task describes what engineering activity is necessary to implement that behavior.

Keeping those concerns separated makes the backlog easier to understand for both development teams and stakeholders.

What Happens After the MVP?

Once the MVP has been delivered, additional functionality can be introduced through new Features.

For example:

Requirement: Automated Customer Onboarding

├── Feature: Customer Onboarding MVP
│   ├── PBI: Account creation
│   ├── PBI: Basic document upload
│   └── PBI: Basic onboarding workflow
│
├── Feature: Document Validation
│   ├── PBI: Validate document format
│   ├── PBI: Detect missing documents
│   └── PBI: Show validation results
│
└── Feature: CRM Integration
    ├── PBI: Create customer in CRM
    ├── PBI: Synchronize customer information
    └── PBI: Handle synchronization errors

This creates a useful separation between the long-lived capability and the increments through which it is delivered.

The Requirement remains stable, while Features can be completed independently.

Features Do Not Necessarily Mean Releases

It can be tempting to equate Features directly with releases:

Feature: Release 1 – MVP
Feature: Release 2
Feature: Release 3

This can work, and some teams explicitly use this model. The original notes contain examples where every release receives its own Feature.

However, it is usually more useful to describe the capability being delivered rather than merely the release number.

Instead of:

Feature: Release 2

prefer something such as:

Feature: Document Validation

The release information can still be represented using iteration paths, target-version fields, tags, or naming conventions.

This keeps the Feature meaningful even after the release has shipped.

MVP Does Not Mean “One Work Item”

An important distinction is that an MVP is a scope concept, not necessarily a single backlog item.

A small capability might indeed fit into one Feature.

A larger MVP may need several Features:

Requirement: New Video Analytics Capability

├── Feature: MVP – Device Configuration
├── Feature: MVP – Analytics Processing
└── Feature: MVP – Alarm Visualization

Together, these Features constitute the MVP.

The important principle is therefore not:

An MVP must always be exactly one Feature.

Instead:

The Feature level is normally the appropriate level for expressing the major deliverable increments that together form the MVP.

The source material similarly allows the MVP to be represented by one or more Features when necessary.

Keep the MVP Small but Valuable

The word minimum is important.

The MVP should contain only the functionality necessary to produce a usable and meaningful first increment.

This means avoiding the temptation to include:

convenience features,
speculative functionality,
advanced configuration,
rarely needed edge cases,
or improvements that can safely follow later.

For example:

Requirement: Object-Based Storage Recording

├── Feature: OBS Recording MVP
│   ├── PBI: Configure OBS storage target
│   ├── PBI: Record video continuously
│   └── PBI: Play recorded video
│
├── Feature: Audio Recording
├── Feature: Alarm-Based Recording
├── Feature: Export
└── Feature: Advanced Timeline Integration

The MVP delivers the basic value proposition first. Everything else can follow incrementally.

Keeping the initial scope small, gathering feedback after delivery, and expanding the capability in subsequent increments are explicitly identified as good practices in the original discussion.

Avoid Growing a Feature Forever

There is another useful consequence of this model.

Once the MVP Feature is complete, do not continuously append all future functionality to it.

For example, avoid turning this:

Feature: OBS Recording MVP

into a permanent container for every future OBS enhancement.

Instead, close the MVP Feature when its defined scope is delivered and create subsequent Features:

Requirement: Object-Based Storage Recording

├── Feature: OBS Recording MVP
├── Feature: OBS Audio Recording
├── Feature: OBS Alarm Recording
├── Feature: OBS Export
└── Feature: OBS Legacy Camera Support

This provides clean completion boundaries and makes progress much easier to understand.

Why This Structure Works

The model combines two desirable properties.

First, the Requirement remains stable. It represents the overall business or product goal even when priorities and implementation details change.

Second, the Features remain deliverable. Each Feature has a defined scope that can be prioritized, planned, implemented, and eventually closed.

This also provides flexibility. Future Features can be reordered without restructuring the Requirement itself—a benefit specifically highlighted in the source discussion.

Recommended Structure

For a capability implemented as an MVP followed by incremental extensions, a good default structure is:

Requirement: Overall capability
│
├── Feature: MVP
│   ├── PBI: Core behavior A
│   │   ├── Task
│   │   └── Task
│   │
│   ├── PBI: Core behavior B
│   └── PBI: Core behavior C
│
├── Feature: Enhancement A
│   ├── PBI
│   └── PBI
│
├── Feature: Enhancement B
│   ├── PBI
│   └── PBI
│
└── Feature: Advanced capability
    └── ...

The hierarchy then has clear semantics:

Requirement = overall capability
Feature     = deliverable increment
PBI         = implementable behavior
Task        = engineering activity

Conclusion

When using an Azure DevOps hierarchy consisting of Requirement, Feature, PBI, and Task, the MVP normally belongs at the Feature level.

The Requirement should represent the broader and longer-lived capability. The MVP is the first meaningful delivery increment of that capability and is decomposed into PBIs containing the essential functionality. Tasks then describe the concrete engineering activities required to implement those PBIs.

Subsequent functionality can be represented by additional Features underneath the same Requirement.

The guiding principle is:

Keep the Requirement stable, make Features deliverable, slice Features into valuable PBIs, and use Tasks only for implementation work.

This approach supports incremental development while maintaining clear traceability from the long-term product capability down to the concrete engineering work.