# Teams and business units

> Group people so access, reporting and planning follow your organisation instead of fighting it.

> For the complete documentation index, see [llms.txt](https://helpdesk.orangescrum.com/llms.txt).

Source: https://helpdesk.orangescrum.com/guide/cloud/admin/teams-and-business-units

---
> **Teams on Pro, business units on Premium**
>
> Team management requires Pro Unlimited. Business units and organisational
> structuring are Premium.

## Teams

A team is a named group of people. Its value is that **membership becomes a
property of the team**, not of every project individually.

- **Without teams**: A new joiner is added to eleven projects by hand. Someone forgets one, and they cannot see the work for a week.

- **With teams**: Add them to the team. Project access follows.

### Designing teams

**Mirror how people actually work**

    Teams that reflect real working groups stay accurate. Teams that mirror the
    org chart go stale within a reorg.

**Keep them stable**

    A team reshuffled monthly provides no benefit over individual assignment.

**Give each an owner**

    Someone responsible for membership.

**Don't over-split**

    Six people in three teams of two is overhead with no payoff.

### What teams give you

| Use | Effect |
| --- | --- |
| Project access | Add the team, not eleven people |
| Assignment | Assign to a team, let them pick up |
| Reporting | Velocity and workload per team |
| Resourcing | Capacity at team level |
| Notifications | Notify a group |

## Business units 

A level above teams: divisions, departments, regions, or legal entities.

Use them when you need to **report and budget** at a level above the team —
"how is the EMEA division tracking against budget?" — not merely to draw an org
chart.

- **You need them**: Separate P&Ls, distinct budgets, or reporting lines that must not see each other's detail.

- **You don't**: One company, one budget, forty people. Teams are enough.

### What they give you

- Budget and cost reporting rolled up by unit
- Resource capacity and utilisation at unit level
- Access boundaries between parts of the organisation
- Portfolio views scoped to a division

## Structure that survives

**Don't rebuild your org chart**

    Org charts change constantly. Model how work is actually grouped, which
    changes far less, and you will not be rebuilding this every reorg.

**Two levels is usually enough**

    Business unit → team → people. Deeper hierarchies produce reports nobody
    reads and access rules nobody understands.

**People work across boundaries**

    Someone can be in more than one team. Structure should not force you to
    pretend otherwise.

**Review after every reorg**

    Stale structure quietly grants access that should have been removed.

## How this interacts with projects and programs

| Concept | Groups |
| --- | --- |
| **Team** | People |
| **Business unit** | Teams |
| **Project** | Work |
| **[Program](https://helpdesk.orangescrum.com/guide/cloud/projects/programs)** | Projects |

Teams and business units organise **who**; projects and programs organise
**what**. They are independent — a program can draw on several teams, and a team
can work across several programs.

- [Users and roles](https://helpdesk.orangescrum.com/guide/cloud/admin/users-and-roles): Permissions for the people in these groups.

- [Resource management](https://helpdesk.orangescrum.com/guide/cloud/time/resource-management): Capacity planning by team and unit.