3 posts tagged with "Team Collaboration"

When developing the next iteration of an integration service while the old one is still being maintained, how do you decide on an approach? This post shows how envisioning possible futures helped us do it in a project for a large government organization.¹

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.