Team mapping assigns each workstream to a specific team with a named owner, so that every piece of scope has one group accountable for it. It sits between two other steps in the Focus practice: it happens after the workstreams have been estimated and validated against real people, and before the release plan sequences them. The artifact it produces is a workstream-to-team map, and the release plan is drawn on top of that map rather than beside it.
Why does a workstream need a named owner?
Because a team name alone does not answer the question a release plan depends on: who do I call when this workstream is late? A workstream mapped to "Platform" gives you a group of eight people, a shared backlog, and no single person who will be asked about it in the next steering review. A workstream mapped to "Platform, owned by the platform lead" gives you both.
The named owner is doing one specific job here. They are accountable for the workstream's delivery and for its outgoing dependencies. When the release plan shows workstream C blocked on workstream A, the owner of A is the person who has to move it, and the person who has to say so early if they cannot. Without that name, dependencies become a shared responsibility, and a shared responsibility on a dated plan is nobody's.
Owner and team are not the same choice, and both matter. The team supplies the capacity; the owner supplies the accountability. One person can own more than one workstream, and often does, but every workstream has exactly one.
How does team mapping work?
Team mapping works by taking the estimated workstreams and the validated capacity and resolving every workstream to a real team and a real person, with no gaps. Along the way it records which workstreams depend on which, and that is what makes the map usable by the release plan and the raw material for dependency ownership in Deliver.
Three rules make the mapping hold:
- One team per workstream. If a workstream genuinely needs two teams, it is two workstreams with a dependency between them, and splitting it is almost always the better answer.
- One owner per workstream, by name rather than role. A role can change occupant mid-initiative and nobody notices.
- No cell may say "TBD", "shared", or the name of a function. Those are the failure mode described below.
What does good team mapping look like?
Every owner has confirmed their workstream directly; ownership assigned in a meeting the owner did not attend is not ownership. The assignments follow the people that capacity validation already named, so the map turns those names into accountability rather than starting over. Owners agree about the dependencies between them, and where two owners describe the same hand-off differently, a dependency somebody did not know about has been found early instead of at integration.
A good map is also kept current and used. It is the answer to "who owns this?" for the life of the initiative, and it makes team load visible: a team that owns most of the workstreams is a sequencing constraint the release plan will have to respect.
What does a workstream-to-team map look like?
For the hypothetical claims intake initiative used across these entries, after the first slice was cut, the map held five workstreams: web form submission, the validation and routing service, an identity service change, operations support tooling, and a routing fallback path. Each had one team and one named owner, and each recorded what it depended on and what depended on it.
Two things became visible only once the map existed. One team, Claims Platform, owned three of the five workstreams, which made it the sequencing constraint rather than the customer-facing work everyone had been watching. And the identity service change, a small piece of work owned by a team outside the initiative, sat upstream of everything else. It was scheduled first in the release plan and given a date its owner agreed to, which it would not have had if the map had stopped at team names.
What goes wrong in team mapping?
A very common failure mode has two spellings: "shared services" and "TBD".
A workstream mapped to "shared services", "the platform team", "DBA", or "security" has been assigned to a function rather than to a team with accountability for this initiative. Functions receive tickets. They do not attend your planning sessions, they do not hold your dates, and they prioritize across every initiative in the organization, not just yours. The work is real and someone will eventually do it, but it is not on anyone's plan until it becomes urgent. That is the mechanism by which a dependency arrives late as a surprise, and it was visible on the map from day one as a cell that named a department.
"TBD" is the same problem with the honesty left in. It usually means the team is not identified, or the work belongs to a group that has not agreed to take it. Leaving it on the map and proceeding to sequencing puts a dated plan on top of an unowned piece of work.
Three other errors recur:
Owner by role rather than by name. "The product owner" is not an owner. It is a description of whoever happens to be in that seat, and it does not survive a reassignment.
Mapping to teams that were never consulted. A team that discovers its assignment when the release plan is published will re-estimate it, and the plan built on the original estimate is already wrong.
Mapping before validating capacity. Assignments made against a team's name rather than against its real availability reproduce every FTE problem that capacity validation exists to catch.
The fix in all three cases is the same: resolve the cell to a real team and a real person, or record it as an unstaffed workstream and escalate it as a portfolio decision. A map with an honest hole in it is more useful than one that is complete because someone typed a department name.
Team mapping vs a RACI matrix
The nearest adjacent artifact is the RACI matrix, and the two are often confused because both put names against work.
| Team mapping | RACI matrix | |
|---|---|---|
| Unit of work | Workstream | Task, deliverable, or decision |
| What it assigns | Delivery accountability and capacity | Roles across four categories |
| Names per item | One team, one owner | Several, by category |
| Primary use | Input to the release plan | Clarifying involvement and consultation |
| Granularity | A handful of rows per initiative | Often dozens |
| When it runs | Focus, before sequencing | Any time, often at kickoff |
A RACI answers who is consulted and who is informed, which team mapping deliberately does not attempt. Team mapping answers a narrower question with a harder constraint: exactly one team delivers this workstream and exactly one person is accountable for it. The two coexist without conflict, and the sequence that works is mapping first, RACI second, because a RACI built before the workstreams have owners spreads accountability across the exact cells team mapping is trying to close.
Where does the map go next?
Straight into sequencing. The release plan orders the mapped workstreams into releases and turns the dependency columns into dependencies with owners and dates, which is what the Deliver practice manages. The agile portfolio management glossary defines the rest of that chain.
If several of your workstreams currently map to a function rather than a team, that is the finding, and it is the kind of problem a PPM4Agile implementation works through with the teams involved.