Team Scopes
What a team owns, cares for, and makes decisions about
Team scope refers to what a team owns, cares for, and makes decisions about over time. It's not just about day-to-day work. It's about the enduring parts of the business or system for which a team provides stewardship. Scopes can take many forms, depending on how your organization is structured. For example, a team might have scope across:
- A segment of the technology stack (e.g., backend APIs, frontend UI frameworks)
- A defined product surface area (e.g., onboarding, billing dashboard)
- A customer segment (e.g., enterprise buyers, small business users)
- A set of capabilities (e.g., authentication, search, analytics)
- A customer journey stage (e.g., activation, retention, renewal)
- A lifecycle stage in an internal value stream (e.g., design, build, rollout)
- A specific market or geography
- A compliance or regulatory domain (e.g., HIPAA, GDPR)
Teams often have multiple scopes, and those scopes can be nested, related, or shared across teams and contexts. Each Scope:
- Has a type (e.g., "Capability," "Surface Area," "Customer Journey Stage")
- Can be nested (Scopes can have parent and child scopes)
- Can be linked to other scopes across types (e.g., a Capability scope linked to a Customer Journey stage)
- Is assigned to teams (usually at the leaf level of the scope tree)
Example
Let's say you have a Scope Type called Customer Journey Stage, and a Scope Type called Capability.
- The scope Self-Serve Signup (a Journey Stage) might be linked to Authentication (a Capability).
- A team assigned to Authentication inherits context from both scopes.
- Meanwhile, another team owns Billing Dashboard, which is a surface area scope but also intersects with the Invoicing capability.
By modeling these relationships, you build a graph of responsibility and domain ownership—far richer than a simple team list or area-of-focus doc.
Scope Features in the Starter Pack
When you log into the Starter Pack, you'll be able to:
- Create a new Scope using a defined Scope Type
- Nest Scopes within each other to form hierarchies
- Assign teams to leaf-level Scopes (and inherit the tree above)
- Assign product groups or areas to higher-level Scopes to influence team options
- Use Scopes as metadata when organizing work, strategies, or metrics
Think of Scopes as a tagging system on graph steroids—a flexible, interconnected way to express enduring responsibilities.
Final Note on Change
Scopes are intended to reflect enduring ownership, but change is natural—and healthy. As strategy evolves, so should scopes. That's why we support versioning scope assignments, tracking changes over time, and even looking back historically to understand how scopes shifted.
You don't need to get it perfect from the start. You just need to start making it visible.
Minimally Viable Scopes
While the Starter Pack gives you a flexible system for defining scopes, we also provide a starting set of scope types that we suggest using out of the box. These are meant to offer multiple "views" on context—not to be exhaustive, but to help you get moving in the right direction.
Recommended Scope Types
| Scope Type | Description |
|---|---|
| Capabilities | Best phrased as "The ability to ______," capabilities should ideally be solution-agnostic and framed around meaningful outcomes for your users. Think of these as levers or muscles your team is helping customers develop. A helpful first pass: "Our team exists to improve data trust and transparency, which depends on our ability to track lineage, manage access, and assess data quality." These can evolve and roll up into broader capability hierarchies over time. |
| Services / Codebase | Understanding which services, APIs, or areas of the codebase a team is responsible for is critical for operational clarity, technical planning, and ownership boundaries. This includes things like microservices, shared components, or internal tools. |
| Customer | Who does the team serve? Is it an internal stakeholder group? An external customer persona? A partner team? Wherever possible, use existing customer language in your org—avoid inventing new terms or segmentations. Try to embed your scope model in the same "customer graph" your organization already uses. |
Scopes as Living Objects
Scopes aren't just static objects—they evolve. Teams change, responsibilities shift, new contexts emerge. The Starter Pack includes features to help you treat scopes as living objects, with structure and flexibility for ongoing maintenance. Here's what's supported:
- Version history of scopes – Track how scopes change over time and view past configurations.
- Comments and discussions – Start conversations directly on scopes, clarify ownership boundaries, or propose changes.
- Visibility into assignments – See which individuals, teams, or groups are currently assigned to each scope.
- Draft status for scopes – Experiment with new scope structures without immediately publishing changes.
- Merging and splitting scopes – Combine overlapping scopes or divide broad scopes into more manageable parts.
- Renaming and reclassifying – Change scope names, types, or parent relationships without losing history.
- Archiving deprecated scopes – Remove unused or legacy scopes from active views while retaining historical data.
- Linking scopes across types – Create and maintain relationships between scopes of different types (e.g., a capability linked to a customer journey stage).
- Scope analytics (optional) – View usage, participation, and work/tag density across scopes to spot gaps or overloads.
Scopes are meant to be durable but adaptable. By treating them as first-class, inspectable, and maintainable objects, your teams can stay aligned over time—without letting the model become stale or brittle.