scoping-and-handing-off-to-teams

What this skill does

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 | Next steps — team commits to completing breakdown by a specific date     |

This is also Phase 2 of the Work Transition Playbook from the originating side. The funnel doc references the playbook explicitly; both perspectives apply.

Before the meeting:

- Send the architecture plan and the PoC PR link a few business days in advance. Teams that read materials in advance bring sharper questions.
- Confirm the team's tech lead and EM will attend.

In the meeting:

- Lead with the why (the problem and the PoC findings) before the what (the architecture plan section). Teams react better to context than to specification.
- Take questions seriously, especially the ones that surface roadmap conflict. The handoff is the right venue for those — Implementation is the wrong one.
- Don't leave without a commit-to-date for the breakdown. "We'll get to it" is how epics decay in backlogs.

After the meeting:

- The team runs its own breakdown session (you are not present).
- The team's tech lead shares the completed breakdown with you.
- You **review for consistency** with the initiative's vision — not to rewrite stories or micromanage. The funnel doc names the question pattern: "this looks good but uses callbacks instead of the async/await pattern from the PoC — was that intentional?"

## Cost/Benefit Analysis

Document in the architecture plan. The funnel doc's framing:

- **Cost:** General size of the effort across teams (sum of team estimates, plus your shepherd time and Architecture Council time).
- **Benefits:**
  - **Quantitative:** bugs reduced, time saved, performance improved, on-call pages reduced.
  - **Qualitative:** developer experience, maintainability, consistency, security posture, future flexibility.
- **Comparison.** Honest. If qualitative benefits dominate, say so — leadership can weigh that. Pretending you have a quantitative case when you don't damages the next initiative's credibility.

## Initiative Priority

Per the funnel doc, work with engineering leadership to set priority against other initiatives and the [Architecture / Engineering Operating Model](https://bitwarden.atlassian.net/wiki/spaces/EN/pages/1286963201) portfolio:

- **Critical:** Blocks major product work or creates significant risk — start immediately.
- **High:** Substantial quality-of-life improvement or risk reduction — schedule within quarter.
- **Medium:** Meaningful improvement, can be scheduled flexibly — within 2 quarters.
- **Low:** Nice to have, will do when capacity allows — opportunistic scheduling.

Update the priority on the BW initiative in Jira.

## Leadership Presentation

Present the plan to engineering leadership at a stakeholder sync. Per the funnel doc, include:

- Problem recap and solution approach.
- PoC validation results.
- Effort estimates and timeline (from team breakdowns — aggregated).
- Cost/benefit analysis.
- Risk assessment.
- Initiative priority.
- Resource ask — which teams, how much capacity, over what timeframe.

Seek an **explicit go/no-go decision**. Executive commitment means: "Yes, we're allocating resources to complete this initiative."

## Operational Prioritization

This is the step the funnel doc explicitly distinguishes from executi