Vanesco Böhm

Azure DevOps has no built-in Release work item type — and the gap has at least six different solutions, each borrowed from a feature built for something else.

Every team shipping software eventually needs to answer the same questions: which stories are going into Release 2.5? Which might slip to 2.6? Can a story belong to both? Who can see this during sprint planning, and who can report on it afterward? The answer depends entirely on which mechanism you reach for — and the trade-offs between them are real and non-obvious.

This article walks through each option using a consistent example: a development team preparing Release 2.5, with a handful of stories that might partially deliver in 2.5 and complete in 2.6, and a product owner who needs release membership visible during sprint reviews and in progress reports.

Companion blog for deciders: Die Architektur der Empirie: Wie die Azure DevOps Struktur Management und Entwicklung vereinen kann

The most consequential Azure DevOps configuration decision you make is also the easiest to get wrong: how to structure your project. Microsoft's default guidance is clear — start with one project and scale using Teams, Area Paths, and Iteration Paths. This guide walks through three scenarios of increasing complexity, including a concrete, tested solution for the hardest case: multiple teams sharing work across multiple products. It also covers the narrow set of situations where a second project genuinely makes sense.