People & Teams

People & teams directory

Scrum Master Guide: People & Teams

The People & Teams endpoints give Scrum Masters programmatic access to the roster and hierarchy that underpin all Jellyfish data. Understanding who is allocatable and how teams are structured is a prerequisite for interpreting any metric or allocation report.

list_engineers returns every active, allocatable person as of a given date — ideal for building a point-in-time roster snapshot or detecting headcount changes.
search_people accepts a name, email, or internal ID via the q param — use it to look up a specific individual before pulling their metrics or allocations.
list_teams uses the hierarchy_level param (integer, starting at 1 for top-level) to scope which tier of the org you see. Pass include_children=true to expand sub-teams in a single call.
search_teams locates a team by name or team ID — useful when feeding a team_id into downstream metrics or allocation endpoints.

People Endpoints

list_engineers

List of all active allocatable people as of a specific date

search_people

Search for people by name, email, or id

Team Endpoints

list_teams

All teams at specified hierarchy level (optionally includes child teams)

search_teams

Search for teams by name or id

Jellyfish API Token

API Explorer

MockMock

Use Cases for Scrum Masters

Three workflows where People & Teams endpoints deliver immediate value:

1. New Member Onboarding

When a new engineer joins, use search_people with their email to confirm they appear in Jellyfish as allocatable. Follow up with list_engineers using today's date as as_of to verify headcount has updated before running any allocation or metrics pull for the sprint.

2. Cross-Team Coordination

Use list_teams with hierarchy_level=1 and include_children=true to map the full org structure before pulling metrics across multiple teams. Knowing which teams are sub-teams of a parent group lets you aggregate data correctly and avoid double-counting effort in cross-team deliverables.

3. Roster Changes

Compare list_engineers snapshots from two different as_of dates to detect roster changes between planning cycles. Engineers who appear in an older snapshot but not a current one may have left or moved teams — a signal to audit any open allocations or sprint assignments tied to that person's ID.