/scoping-and-handing-off-to-teams

name: scoping-and-handing-off-to-teams
description: Phase 4 (Scoping & Commitment) deep-dive playbook — High-Level Architecture Plan, child epics, per-team handoffs, leadership go/no-go.
when_to_use: Use when an initiative has cleared PoC and the shepherd is scoping the work, drafting the architecture plan, handing off to teams, and seeking leadership commitment. Triggers — "handoff meeting", "drafting the architecture plan", "writing child epics", "go/no-go". Not for Phase 5 coordination (use `coordinating-implementation-across-teams`).
allowed-tools: Skill, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_issue_remote_links, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_issues, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__get_confluence_page_comments, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence, mcp__plugin_bitwarden-atlassian-tools_bitwarden-atlassian__search_confluence_cql

Phase 4 (Scoping & Commitment) deep-dive playbook for an initiative shepherd — the final decision gate before significant resource allocation. The shepherd transitions from leading the work to supporting the teams that will execute it. Deliverables: the High-Level Architecture Plan, child epics, per-team handoff meetings, cost-benefit analysis, leadership go/no-go presentation, operational prioritization, capacity allocation, and the finalized ADR. Time budget: 2–4 weeks, 30–50 hours of shepherd time. Composes `Skill(running-work-transitions)` in `bitwarden-delivery-tools` for the originating-side Preparation and Transition Sessions phases of the [Work Transition Playbook](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/2521038855).

The Anti-Pattern to Reject First

Before anything else: **the team owns the breakdown — not the shepherd.** The single biggest failure mode at this phase is the shepherd writing the team's stories.

The funnel doc is unambiguous: "After the handoff, run a team breakdown session. The team creates the stories — not the shepherd." Stories the team didn't write are stories the team won't own. Once that happens, downstream failure shows up as "we're behind schedule because the stories don't match how the team actually works" and there's no clean recovery.

Hold the line. Your job is to give each team enough context, scope, and pattern to break the work down well — not to break it down for them.

What You Produce

Phase 4 produces eight artifacts, in roughly this order: the High-Level Architecture Plan, child epics in Jira, the per-team handoff meetings, a cost/benefit analysis, the assigned initiative priority, the leadership presentation for go/no-go, operational prioritization with capacity allocation, and the finalized ADR. Each follows below as its own section.

The High-Level Architecture Plan

A Confluence page placed under the EN-space architecture-planning folder, following the "High-Level Architecture Planning" template. The funnel doc specifies its content:

• **Scope.** What will be changed — repositories, modules, files. Be specific. Vague scope at this stage means re-scoping during Implementation.
• **Approach.** How the change rolls out. Phasing, migration path, what happens to the old pattern during and after the migration.
• **Team alignment.** Which teams own which portions. One team per epic when possible.
• **Dependencies.** What must happen first. What can happen in parallel. Where teams will block each other.
• **Risk mitigation.** Failure modes, rollback plan, what indicators trigger a pause/pivot.
• **Success metrics.** How you will know the initiative succeeded. Define these now — they become the basis for the impact measurement 3–6 months after Implementation completes.
• **Documentation needs.** What must be created or updated as the rollout progresses (technical guide, migration guide, ADR updates, contributing-guide changes, runbooks).

The architecture plan is the document each team's tech lead reads before the handoff meeting. Write it for that reader.

Child Epics in Jira

Create epics under the BW initiative — typically one per team or major module. Each epic carries:

• **Summary.** Short and concrete (e.g., "Migrate Browser Extension to New Error Pattern").
• **Team assignment.** Assign to the team, not an individual.
• **Description.** What area of the codebase is affected; what pattern is being adopted (link to PoC PR); expected outcomes for this epic; success criteria; cross-team dependencies the team needs to know about.
• **Label / component** for filtering (e.g., `initiative-typescript-migration`). This is how everyone's dashboard rolls up progress later.

Example epic shape from the funnel doc:

> **Epic:** Migrate Browser Extension to New Error Pattern > **Team:** Browser Extension Team > **Description:** > > - Adopt error middleware pattern proven in PoC (PR #1234) > - Apply to background scripts, content scripts, and popup > - Must maintain existing error reporting to Sentry > - **Success:** All extension error handling follows new pattern, zero regressions

What does not go in the epic: the implementing stories. Those come from the team's own breakdown session.

Per-Team Handoff Meetings

Schedule one handoff meeting per team, 1 hour each. Per the funnel doc, the structure is:

| Time | What | | ------ | ------------------------------------------------------------------------ | | 20 min | Shepherd presents: PoC findings, architecture plan section for this team | | 15 min | Q&A — team asks clarifying questions about approach | | 15 min | Team discusses: initial thoughts on breakdown approach | | 10 min | Nex