How to write customer-facing release notes from Azure DevOps work items

Short answer: Add a "Release note" field to your work item form and have the person who closes the item write one customer-facing sentence in it. Generate the release notes from a query that selects closed items with that field filled in, sorted into features, improvements and fixes by rules. The team keeps its technical titles. The customer gets a document someone wrote for them, one sentence at a time.

On Microsoft Q&A a Scrum Master asked how to "link tickets to release notes" in Azure DevOps, and the thread never got past "there is no release notes feature". Practitioner blogs have converged on the same answer for years: capture the customer wording inside the work item, review it before release, and automate the assembly. This article walks through that setup.

Why exported work items make bad release notes

A query of closed items gives you lines like these:

• Fix NRE in OrderService when shipping address is null
• Refactor invoice PDF generation
• Spike: evaluate caching for product search

The first is a real customer fix described in developer language. The second is invisible to the customer. The third should never be published. Release notes generated straight from titles are accurate and useless. Someone ends up rewriting them in Word the night before the release, and that person becomes the bottleneck.

Step 1: Capture the customer sentence in the work item

Add a custom field to User Story, Product Backlog Item and Bug, for example Release note (type: text, multi-line, or HTML if you want formatting). Two rules make it work:

1. Written by the person closing the item, in the customer's words. "Orders with a missing shipping address no longer fail at checkout" rather than the title above.
2. Empty means internal. Refactorings, spikes and infrastructure work leave the field blank and are automatically excluded.

Some teams write the release note when the item is created, as a definition of what "done" will look like from the outside. A good habit, and optional for getting started.

Optionally add a Release note audience picklist (Customer, Internal) when one product serves both.

Step 2: Select the items with a query, not a build

Create a saved query such as:

• Work Item Type in User Story, Bug
• State = Closed
• Release note is not empty
• Closed Date >= @StartOfDay('-14d')

or, if you tag releases, Tags contains 4.12. The product owner can run this query at any time and see exactly what will be published, which is the review step most teams were missing.

Step 3: Sort items into sections with rules

Readers expect three or four sections: new features, improvements, fixes, known issues. Do not sort by hand. Define rules once:

In Bravo Notes these rules are called labels and are saved with the template, so every release uses the same classification.

Step 4: Generate the document from a template

The template references the custom field and never the title, so the technical wording cannot leak:

# What's new in {{ param 'ProductName' }} {{ param 'Version' }}

{{ date 'd mmmm yyyy' }}

{{#section 'new-feature'}}
## New features
{{#workItems orderBy='Priority'}}
### {{ field 'Custom.ReleaseNoteTitle' }}
{{{ field 'Custom.ReleaseNote' }}}
{{/workItems}}
{{/section}}

{{#section 'improvement'}}
## Improvements
{{#workItems}}
- {{{ field 'Custom.ReleaseNote' }}}
{{/workItems}}
{{/section}}

{{#section 'bugfix'}}
## Fixes
{{#workItems}}
- {{{ field 'Custom.ReleaseNote' }}}
{{/workItems}}
{{/section}}

{{#section 'known-issue'}}
## Known issues
{{#workItems}}
- {{{ field 'Custom.ReleaseNote' }}}
{{/workItems}}
{{/section}}

Questions? Contact {{ param 'SupportEmail' }}.

Custom fields are referenced by their full reference name, which you find in the process customization under Organization settings. Parameters such as ProductName, Version and SupportEmail are filled in once per release.

Work items in the query without release note text fall out of every section, because the label rules require the field. Nothing technical leaks by accident.

Step 5: Review, then publish everywhere at once

Open the preview, read it as a customer would, fix wording in the work item (not in the document), refresh. When it reads well:

• Export to PDF for the customer email, with a cover page and your logo.
• Export to HTML for the website, help center or Confluence.
• Send by email to the support mailbox and the Teams channel.

For teams that release on a schedule, the Bravo Notes build task runs the same template from a pipeline with the query as its source and publishes the result to a Wiki page, a repository, Confluence or email. The release notes become a by-product of closing work items properly.

Two things that only sound like shortcuts

"We will just clean up the titles." Titles are for the team. Making them customer-friendly makes them worse for triage, code review and search. Keep both.

"We will let an AI rewrite the titles." Generated text that nobody checked is how you tell customers about a feature that is behind a flag or a fix that was reverted. An AI assistant is useful for a first draft of the release note field, reviewed by the person closing the item. It is not a substitute for the field.

Frequently asked questions

Where should customer-facing release note text live in Azure DevOps? In a custom field on the work item, written by the person who closes it. It is versioned with the work item, searchable, and available to any tool that reads work items.

How do I exclude internal work from customer release notes? Leave the release note field empty for internal work, and build the query or label rules so that only items with text are included.

Can release notes be generated per customer or per product line? Yes. Add an audience or product field and filter by it in the query or label rules. One template can produce several documents by changing a parameter.

How do we keep release notes consistent between releases? Save the template, labels and parameters once and reuse them. In Bravo Notes everything is saved with the document, so the next release is "add work items, review, export".

Can this be fully automated? The assembly can. Writing the one customer-facing sentence per item cannot be automated, and it is the part worth keeping by hand.