Teams

A team is a named group of people inside a workspace. On its own that is just a list, but teams earn their place by doing one job well: they are how you grant a group access to the work it should be able to see and change. Instead of opening a private portfolio to one person at a time, you link it to a team, and everyone on the team gets in. Add someone to the team later and they inherit that access; take them off and it goes with them.

This page is about building and running teams: creating one, adding people at the right level, linking it to the portfolios and projects it should reach, setting how the team works, and handing it on. For who a person is across the whole workspace, see members and invitations; for what the work itself is, see portfolios and projects.

What a team is for

The reason to make a team is access. A portfolio or a project can be public, open to everyone in the workspace, or private, visible only to the people who have been let in. A private one stays genuinely closed: someone with no path to it does not just lack edit rights, they cannot see it exists. Linking a team to that private portfolio or project is the path. Every member of the team can then read and work in it, and the link is the single place that grant is recorded.

This is what makes a team worth maintaining rather than handing out access by hand. When Sarah Chen stands up an Analytics team and links it to the private Insights portfolio, the four people on her team can all work in Insights from that one link. When a fifth person joins the team, they get Insights too, without Sarah revisiting the portfolio. When someone rolls off, their access leaves with their membership. The team is the group; the link is the grant; the two together are how access stays correct as people move.

A public portfolio or project needs none of this, because it is already open to the whole workspace. Teams are for the private work, where access is a decision and the team is how you make it once for a group instead of repeatedly for individuals.

Create a team

Teams live under Settings → Teams. Choose Create team, give it a name and an optional description, and it is made with you as its owner. A fresh team has no members but you and no links yet; filling it in is the rest of this page.

A team's own page is organized into tabs, General, Members, Portfolios, Projects, and Sprints, each with a count so you can see the shape of the team at a glance: how many people, how many portfolios and projects it opens, how many sprints it runs. The first four are the subject of this page; the Sprints tab is where the team's sprints live, created by anyone with sprint-management rights and each opening into its own backlog, and it is covered in sprints.

Add people to a team

You add a member from the team's Members tab, choosing the person and the level they join at: Viewer, Contributor (the default), or Planner. You add people who already belong to the workspace, so to bring in someone new, invite them to the workspace first.

Two different things follow from joining a team, and it helps to keep them apart.

The level sets what a person can do to the team itself: a Viewer can see the team, a Contributor takes part in it, and a Planner runs it, its members, its links, and its settings. That is the ladder you are choosing from when you pick a level.

Membership is the other thing, and it is what grants access to the work the team is linked to. This part does not vary by level. Everyone on the team, viewer and planner alike, can get into the portfolios and projects the team is linked to and work in them. The level decides your standing in the team; being on the team at all is what opens the linked work. When Priya Patel joins the Analytics team as a Contributor, she gets into the linked Insights work exactly as a Planner would; her level shapes only what she can do to the team itself, not what she can reach through it.

The person who owns the team holds it as a structural fact rather than a level you pick; their row is the owner's row, and the level choices are for everyone else. What each level grants over the team in detail, and how these team levels sit alongside the workspace-wide roles, is in roles and permissions; here it is enough to know that you choose a person's level as you add them, and change it later from their row.

Link portfolios and projects

Linking is done from the team's side, on its Portfolios and Projects tabs. Choose Link portfolio or Link project, pick from the ones you can see, and the team's members gain access to it. Unlinking takes that access away again, cleanly, for everyone the link was carrying.

Linking is intentionally a two-sided action. To link a portfolio to a team you need the right to manage the team's members and the right to manage that portfolio, because the link reaches across two things and you should hold authority over both ends of it. You cannot quietly grant your team access to a portfolio you do not yourself control, and you cannot attach an arbitrary portfolio to a team you are not entitled to shape. The same holds for projects. It is a small gate that keeps the access grant honest: a link only ever exists where someone with standing on both sides chose to make it.

When work is linked to more than one team

A link is not exclusive. The same portfolio or project can be linked to more than one team, so a person can reach the same work through any team they share with it, and the access they get is identical however they arrive. This is what lets a shared service project belong to every team that touches it, without anyone tending a tangle of individual grants.

The two-sided rule also has a deliberate edge for administrators, and it is worth stating plainly. A workspace admin with the right scope can read any portfolio or project, which is what audit and support need. But editing a private one still means being on a linked team. There is no admin write-around. That asymmetry is the point: it keeps the question "who can change this work" answerable by the work's own teams, rather than quietly bypassed by a broad role. The reach to look is wide; the reach to change is earned through membership.

Transfer team ownership

A team has one owner, the same way a workspace does, and ownership can move. From the team's menu, Transfer ownership hands the team to another member. The hand-off is clean: the person taking over becomes the owner, and the outgoing owner steps down to Planner on the team rather than dropping off it, so the team is never left without an owner and the former owner keeps working in it. Only the current owner can start the transfer, the new owner has to be an active member of the workspace, and the team announces the change so it is on the record.

This is the same instinct as workspace ownership, applied at the team scale: the single accountable seat moves in one deliberate motion, and it never sits empty in the middle. The owner's row carries no remove action for the same reason; ownership leaves a team by transfer, not by removal.

Working days, estimation, and capacity

A team's General tab carries the settings that describe how the team operates. These feed planning rather than access, and they all start from one choice.

Begin with the estimation unit. A team measures effort in hours or in story points, and that single choice flows through everything else: sprint planning, capacity, and the team's reports all read from it. It is the setting to get right first. Changing it later is a deliberate step rather than a quick toggle, because the team's sprints, initiatives, and reports re-read from the new unit; Disco Parrot shows you what will be affected before you switch. The General tab also carries a couple of switches that turn on AI estimate suggestions and the AI report builder for this team's work.

From there you set the team's working days, the weekdays that count when capacity is worked out, and its capacity defaults, the baseline a person on this team is expected to carry. The defaults are expressed in whichever unit the team uses, and you can set one for the team as a whole and finer defaults per level.

These are starting values, not the final word. They give every sprint a sensible baseline so planning does not begin from zero, and the per-sprint, per-person numbers are tuned on the sprint itself. The full mechanics of sprint capacity, the overrides, the days off, the way a team default flows down into a sprint member's number, live in sprints; the team page is where the defaults that feed it are set.

The General tab also holds the team's estimation unit, hours or story points, which the capacity defaults above follow, alongside switches that turn on AI estimate suggestions and the AI report builder for this team's work. The estimation unit is the one to get right, because sprint planning and reports across the team read from it.

Who can manage teams

Everyone in the workspace can see teams and open them, on teams.read, which every role holds, because the existence of a team and who is on it is not privileged. Creating, renaming, and deleting teams rides on teams.manage, and adding or removing members, transferring ownership, and linking work ride on teams.members.manage. Those management scopes belong to the Admin role and to the Planner role, so the people who run planning can build the team structure that planning depends on without needing to be full workspace administrators.

Why teams work this way

Access is the hardest thing to keep correct in any tool that more than a few people use, because it drifts. Someone is granted a folder for one task and keeps it for a year; someone leaves and their access lingers; a new hire spends a week collecting the permissions everyone else already has. The cause is almost always the same: access was handed out one person at a time, so there is no single place that says who should be able to see a thing, and no single motion that fixes it when the answer changes.

A team is that single place. It names a group once, and the link from the team to a portfolio or project records the grant once. Add a person to the group and they inherit every link the group carries; remove them and it all leaves together. Access follows membership, so the question "who can get into this work" has one answer that lives on the team, not a scatter of per-resource exceptions. And because a private portfolio is genuinely invisible without a path to it, the team is not just a convenience over per-person sharing; it is the mechanism by which closed work is opened to exactly the group that should have it, and no one else.

The two-sided link is the discipline that keeps this from becoming a back door. You can only join a team to work you already control, so a team can never be used to reach around the permissions on a portfolio or project. Access through a team is always access someone with standing on both sides chose to grant, which is what lets you trust the group as the unit of access rather than auditing every individual.

For a team lead, a team is how you give your whole group the right access in one move and keep it right as people come and go. Build the team, link it to the work, and set each person's level; the access takes care of itself from there.

For an engineer, a team is why you can see the projects you are meant to and not the ones you are not. Your access follows your membership, so joining a team opens the right doors and leaving closes them, with nothing to chase down.

For an administrator, teams are the structure that keeps access legible. Instead of a sprawl of per-person grants, you have groups linked to work, each link made by someone entitled on both ends, each membership carrying its own level. It is access you can read at a glance and reason about.

For the person who owns a team, the model gives you a group you can shape and hand on without losing the thread. Add and remove members, set their levels, link and unlink the work, and when the time comes, transfer the team in one clean motion that leaves it owned and loses no one.