10 minute read
- How often a working group changes should not determine Azure DevOps Team boundaries; Teams should surround the wider group that holds lasting accountability. see why — jump to the section that argues this
- An Azure DevOps Team is a durable planning and routing container, not just a filtered list, so creating Teams for temporary groupings creates unnecessary configuration and history. see why — jump to the section that argues this
- Frequently reshuffling working groups are better represented by shared backlogs plus governed tag filters than by repeatedly creating and deleting Azure DevOps Teams. see why — jump to the section that argues this
- Model Azure DevOps Teams around the wider group with lasting accountability for products or services, not around temporary working groups that reshuffle each Sprint.
- For reshuffling working groups, keep one Azure DevOps Team and use a governed working‑group tag convention and personal filters instead of creating new Teams.
- Run a time‑boxed experiment: give one reshuffling group a single Team and board, tag their work, then inspect visibility, lost capabilities, and delivery numbers before adding separate Teams.
Model what is stable. Filter what is temporary.
When an Azure DevOps Team boundary sits too low, I see the same pattern: people spend their time battling the tool instead of using it.
- New Teams keep appearing. Each time people regroup, another Team appears, with its own board, backlog, iterations, and settings to configure.
- People keep moving between Teams. Each regrouping means changing memberships and rerouting work so that it appears on the right board.
- Individuals look at more than one Team. A person who belongs to several Teams checks several boards, and in my experience no single Team board shows all of their work.
The last symptom concerns me most, because nobody looking at one Team board can see that person’s work whole. Some roles legitimately span Teams, so it is a signal to investigate rather than proof of a bad design.
The cost does not stay with that person. In my judgement it reaches the leaders who rely on those boards: work is hidden from the views they use, the picture of who owns what becomes unreliable, and the organisation of the work becomes less transparent.
Your collaboration may change more often than your accountability
These symptoms usually begin with a reasonable impulse. People form different working groups from one Sprint to the next, and it is tempting to create an Azure DevOps Team for each new working group. The organisation changed, so the tool should change with it.
I think that is usually the wrong design decision.
How often a group changes is not the same as how long it lasts. People can regroup every Sprint without any one grouping becoming something that owns work for long. If your Teams follow every regrouping, settings meant to last change as often as the groups do.
Taken together, the symptoms say the Team sits one level too low: around each working group instead of around the wider group that stays accountable. Put the Team around that wider group, then check that the upkeep drops and ownership stays clear.
An Azure DevOps Team should stand for what a group keeps owning: a product or service, the decisions about running it, and the planning features that support that. Groups that change often are better shown as a view over shared work.
Suppose a wider engineering group remains accountable for the same products, services, and outcomes, but its members work in different combinations from Sprint to Sprint. The working groups change. The accountability does not necessarily change with them.
I saw this on a migration. A product group whose people regrouped every Sprint asked for a Team for each subgroup. I recommended one Team with tag filters, and sub-teams only if that proved painful. The worst outcome I wanted to avoid was a person checking two boards to see their work. In the Poppendiecks’ seven wastes of software development, that person pays for task switching between boards, partially done work hides on the board they did not open, and items sit waiting until someone happens to look. I have seen many groups like this across migrations.
A Team for each working group gives every temporary grouping a lasting place in the tool. That feels responsive, because the board matches today’s grouping. But every later reshuffle then means another change to the Teams.
In my experience, old Azure DevOps settings pile up and make work: people have to find out which settings still mean something. Teams made for working groups are not the only cause, but they add to it.
If your organisation creates and deletes these Teams with discipline, the overhead may be small. If old Teams disappear cleanly, with nothing left misrouted or hard to find, moving the Team up a level may gain you little.
An Azure DevOps Team is more than a filtered list
An Azure DevOps Team is more than a name on a list of work. Creating one sets up routing and settings that someone has to understand and maintain, and it builds up planning history as it is used.
Microsoft’s overview of Azure DevOps settings connects Team settings to backlogs, boards, iterations, dashboards, and widgets. Area Path assignments determine which work appears on Team backlogs and boards.
Area Path routing explains one source of the Teams that keep appearing. In my experience, organisations that have used the product since before Team Foundation Server (TFS) 2012 often still treat the Area Path tree as a breakdown of their work. TFS 2012 introduced the Team, and the Area Path became the way work is routed to a Team. In the TFS era Microsoft also offered a Team Field, an alternative field for routing work to Teams, and in 2015 I wrote about nested teams using either approach. Microsoft’s documentation for it is now archived, and states that Team Fields were supported only on on-premises Azure DevOps Server with the XML process model, and that a Team could use a Team Field or Area Paths, not both.
From Microsoft’s product decisions, and from my conversations with the product team, I am clear that the Area Path in its current form is for Team organisation, not for breaking work down below a Team. An Area Path hierarchy that follows products and Teams down to each Team’s node is fine. The problem is breakdown below that node. An organisation that keeps such a tree usually wants each branch to have its own configured board and backlog, and only another Team provides that; a filtered view of a branch needs no new Team. In my view, Azure DevOps is a system for creating value, not a work breakdown system, which is why I would carry the breakdown in tags instead.
A separate Team earns its keep when a group has to keep planning and owning work together. It is wasted effort when all you need is to change what someone sees this Sprint.
Temporary working groups need a shared, governed tag convention
Azure Boards can filter boards and backlogs by tags and other fields. Filter settings are user-specific, saved automatically, and retained across sessions and devices.
That gives individuals a reversible way to focus on a subset of a shared backlog. A tag identifies the work associated with a working group without turning that working group into another Team.
The filters are personal, but the tags they depend on are shared, so the convention needs an owner. I would make the wider Team’s accountable lead the owner of the tag convention: who creates and retires working-group tags, how they are named, and how missing or stale tags are detected. Without that ownership the organisation replaces too many Team objects with too many unmanaged tags, and personal views present different accounts of the same work.
Filters cannot be shared as a common Team configuration or set as a Team default. Filtering also changes backlog behaviour: reordering and forecasting are unavailable while a filter is active. A filtered view is therefore not a lightweight Team with all the same capabilities.
A tag filter is a view, never a second backlog. The wider Team’s backlog is ordered by whoever owns that product backlog, who may be a different person in a different role from the owner of the tag convention.
Filters do not replace a Team when accountability persists
A working group may need velocity, dashboards, or a durable operational identity. A personal tag filter does not provide all of those.
Some dashboards and widgets only work per Team. A group that stays accountable for a service, makes its own operating decisions, or needs those Team-only planning features may need its own Team, even if its members change. The test is not whether the people stay together forever. It is whether the ownership and the features they need last long enough to justify a Team.
Azure DevOps velocity records completed work across previous Sprints to help a Team forecast future capacity, and Microsoft warns against using it as a key performance indicator. A working group that exists for one Sprint has no stable history, so treating its number as a trend assumes continuity it does not have.
So losing a separate velocity chart may be fine. Losing a planning feature or operational boundary you really need may not be.
People commonly give two other reasons for a separate Team: capacity and cadence.
Sprint capacity settings are not a reason to keep or create a Team. I do not recommend any capacity-planning tool, in Azure DevOps or anywhere else. I treat “Are we full?” as a question for WIP limits on the whole system, set on the wider Team’s board rather than on a filtered view, and I have written about why capacity is a property of the whole system.
I would not treat cadence as a reason either. Everyone working on one product or delivering together shares one cadence. In my view, a working group that needs a different cadence usually signals a different product, not a different Team.
Subscribe to Martin's articles
Writing since 2001
Articles, usually weekly on Mondays. One click to leave.
Try one Team before you change everything
Take one group that keeps reshuffling, say twenty people who form three or four working groups each Sprint. Before you change anything, note how many boards each person checks and how many Team changes you made the last time they reshuffled. Pick one delivery number you already watch, such as how long items take from start to done.
Then give the twenty people one Team and one board. Mark each piece of work with a tag for the working group doing it, and let each person filter the board by their tag. Run it for a few Sprints.
Afterwards, ask: does each person now see all their work on one board? Can their lead see everyone’s work? Did anyone lose something they genuinely used, like an on-call rota or a dashboard? Did the delivery number get worse? If people lost something they need, that group needs its own Team. If not, you have fewer Teams to maintain and nobody’s work is hidden.
Before you create another Azure DevOps Team, ask:
- Is it actually a team, or a group that will reshuffle next Sprint?
- Does it own something on its own, such as a service or an on-call rota?
- Does it make decisions the wider Team cannot make for it?
- Does it need a different cadence? If so, is it really a different product?
- Will its history still mean anything when its members change?
- Who will tidy up the Team when the group changes?
If the answers point to a lasting team that owns something, create the Team. If they only show who is working with whom this Sprint, keep one Team and change the view. Then look again at the person who had several boards to check. If they now see all their work on one board, and their lead can see it too, the boundary is in the right place.
Was this useful?
Enjoyed this? One click, no account.
Questions this answers
How should I decide when to create a new Azure DevOps Team versus using filters or tags?
Create a separate Azure DevOps Team when a group has lasting accountability for a product or service, needs its own planning features (like dashboards, velocity, on-call rotas), and will keep owning and planning work together over time. If the group is a temporary working group that reshuffles frequently and only needs a different view of shared work, keep one Team at the higher accountability level and use tags and personal filters instead of adding more Teams.
How can I handle temporary or reshuffling working groups in Azure DevOps without constantly creating new Teams?
When working groups reshuffle frequently, keep a single Azure DevOps Team around the wider accountable group and represent temporary groupings with shared, governed tags. Let individuals use personal board/backlog filters on those tags to see their subset of work, and ensure someone owns the tag convention so tags are created, named, and retired consistently.
What does it mean for an Azure DevOps Team boundary to be 'too low', and how do I fix it?
A Team boundary is too low when it is defined around short-lived working groups instead of the wider group that remains accountable for products and services, leading to people belonging to multiple Teams, many boards to check, and frequent Team reconfiguration. To fix it, move the Azure DevOps Team boundary up to the stable accountable group, reduce the number of Teams, and represent temporary groupings with filters and tags so each person and their lead can see all their work on one board.
Why shouldn’t I use Azure DevOps Teams for every branch of my Area Path or work breakdown?
Microsoft now positions Area Paths for Team organization rather than fine-grained work breakdown, and treating each Area Path branch as its own Team leads to many Teams, duplicated configuration, and unnecessary overhead. Use the Area Path hierarchy down to each Team node, but avoid breaking work down further with separate Teams; instead, carry detailed breakdowns in tags and views unless a group truly needs its own enduring Team-level planning and ownership.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.