Structuring an Azure DevOps backlog for a D365 programme

Use the backlog as a governance model

Microsoft provides a business process catalog and a Dynamics 365 deliverables tree that can be imported into Azure DevOps. They are useful accelerators, but ownership and hierarchy must still reflect the actual programme.

I separate three dimensions: the business outcome, the solution capability and the engineering work. They must be linked rather than compressed into one overloaded work item.

See Import the business process catalog into Azure DevOps and Dynamics 365 Deliverables Tree and Work Item Types.

A pragmatic hierarchy

Area paths and iteration structure

Area paths represent the ownership dimension (who owns this work), while iterations represent the time dimension (when is it planned). Both must be configured before the backlog is populated.

Area path structure (example):
D365-Programme
├── Finance
│   ├── Accounts-Receivable
│   └── General-Ledger
├── Supply-Chain
│   ├── Procurement
│   └── Inventory
├── Integration
└── Infrastructure
    ├── ALM
    └── Security

Iteration path structure:
D365-Programme
├── Sprints
│   ├── 2026-S01 (Jul 7 – Jul 18)
│   ├── 2026-S02 (Jul 21 – Aug 1)
│   └── 2026-S03 (Aug 4 – Aug 15)
├── Releases
│   ├── Release-1.0 (Aug 29)
│   └── Release-1.1 (Oct 3)
└── Backlog (unscheduled)

Area path assignment drives who sees the work in their team board. Iteration assignment drives sprint planning. Keep area paths stable; iterations are added by release cadence.

An actionable D365 user story

## Business context
Customer credit is checked during sales order confirmation for FR01 and BE01.

## Expected rule
Block confirmation when calculated exposure exceeds the limit,
except intercompany orders (order type = Journal).

## D365 scope
SalesTable confirmation → credit management module → SalesFormLetter_Confirm.
Standard check via CustVendOpenTransManager.

## Acceptance criteria
- below limit: confirmation succeeds, no message
- above limit: explicit Infolog message, no document generated
- intercompany (Journal type): standard behaviour unchanged
- batch confirmation: same rule applied; actionable error log entry per order

## Non-functional constraints
No external HTTP call inside the confirmation transaction.
500 orders processed in batch in under five minutes.

## Required evidence
SysTest class linked to PR, UAT signoff from credit controller,
technical note including impacted objects and performance measurement.

Definition of Ready and Definition of Done

Expose technical risk

Use controlled tags such as Extension, Integration, DataMigration, Security, Performance, Reporting and Localization. They drive cross-team queries and dashboard views.

• Affected objects, models and extension points.
• Interface, batch or data entity scope.
• Criticality and deployment window.
• External-team or ISV vendor dependencies.
• Rollback or feature-disable strategy.
• Load or security testing requirement.

Use a Spike for uncertainty. A Spike must produce a concrete output: prototype, measurement, ADR, revised estimate or a documented recommendation. A Spike with no output is just deferred work.

Azure Test Plans integration

Azure Test Plans provides the bridge between a user story and its validation evidence. In a D365 programme, linking test cases to stories and bugs is the primary way to answer "is this feature fully validated?"

Each test case records: preconditions, steps, expected result, actual result and attachments (screenshots, log extracts). Closing a Story without a linked passing test case violates Definition of Done and should be caught in sprint review.

Build end-to-end traceability

The minimum traceability chain is: process → story → tasks → commit/pull request → build artifact → test plan → bug → release. Automate links through branch policies, commit message conventions and pipeline configuration.

A release should answer three questions without relying on email or tribal knowledge: which requirements are included, which immutable artifact was deployed and which evidence validates the outcome?

Useful queries and metrics

• Ready stories without estimates or acceptance criteria.
• Pull requests open for more than two business days without a reviewer.
• Critical bugs by process area and environment.
• Completed stories without a linked passing test case.
• Release items with unresolved dependencies.
• Lead time: Ready → development start → UAT acceptance → production.
• Reopen rate after UAT — a leading indicator of inadequate acceptance criteria.

Flow time and output quality are more useful signals than raw velocity. More completed points are not a success if defect and rework rates rise concurrently.

Common anti-patterns

• "Develop the interface" without a defined contract, volume expectation or error handling strategy.
• Technical tasks used instead of acceptance criteria at story level.
• A bug closed when code is delivered but not validated in the target environment.
• Permanent Epics spanning several years with no measurable milestone.
• Free-form tags creating many synonyms (Perf, Performance, perf-issue).
• A release record with no link to its deployable package and deployment checklist.

See also

• Azure DevOps YAML pipeline for D365 F&O — the CI/CD pipeline that executes what the backlog describes
• Git and X++ — linking commits and pull requests to work items
• Deploying a D365 F&O package through LCS — release traceability and go/no-go governance

Microsoft Learn references

• Azure DevOps backlog configuration for the business process catalog
• Import the business process catalog into Azure DevOps
• Dynamics 365 Deliverables Tree and Work Item Types
• About work items and work item types
• Azure Test Plans overview