Skip to content

Team Workflow Templates

This guide provides seven production-ready workflow templates that teams can adopt with minimal customization. Each template specifies the persona composition, stage sequence, handoff protocol, success criteria, and anti-patterns to avoid. Use these as starting points rather than rigid blueprints -- expect to adapt them to your team's tools, cadence, and domain.

All templates assume you have installed FCC and loaded the default persona registry. See the Getting Started guide if you have not completed that step.

How to Use These Templates

Each template follows the same structure:

  1. Purpose -- when to use the template
  2. Persona composition -- the 3-7 personas involved and why
  3. Stage sequence -- the Find, Create, Critique phases in order
  4. Handoff protocol -- what each stage produces for the next
  5. Success criteria -- how you know the workflow succeeded
  6. Mermaid diagram -- visual reference for the flow
  7. Anti-patterns -- common mistakes to avoid
  8. Scaling considerations -- how the template changes as teams grow

Adaptation guidance

Start by running the template as-is for 2-3 cycles. Only customize after you have observed where the default falls short for your team. Premature customization tends to hide problems rather than solve them.

Template 1: Design Review Team

Purpose

Evaluate a proposed technical design before implementation begins. Use this template for any change that touches multiple services, introduces new dependencies, or affects more than one team.

Persona Composition

Persona Role in Workflow Why Needed
Research Crafter (RC) Pulls in prior art and constraints Prevents rediscovery and missed context
Blueprint Crafter (BC) Presents the design under review Author and advocate
Blueprint Validator (BV) Structural critique Catches design-level flaws
Governance Compliance Auditor (GCA) Policy and constitution check Ensures standards alignment
Collaboration Orchestrator (CO) Runs the session Handoffs and timeboxing

Stage Sequence

Find (15-25 minutes)

RC surfaces prior decisions, existing ADRs, related systems, and constraints. Output is a structured context brief of under 400 words with links.

Create (25-40 minutes)

BC walks through the design with four required sections: problem statement, chosen approach, alternatives considered, trade-offs accepted. Attendees ask clarifying questions only -- no critique yet.

Critique (30-45 minutes)

BV and GCA score the design on six axes (clarity, feasibility, trade-off rigor, testability, governance alignment, risk coverage). CO aggregates scores and facilitates discussion on any axis below 3/5.

Handoff Protocol

flowchart LR
    RC[RC<br/>Context Brief] -->|structured markdown| BC[BC<br/>Design Doc]
    BC -->|annotated design| BV[BV<br/>Structural Review]
    BC -->|annotated design| GCA[GCA<br/>Policy Review]
    BV -->|scorecard| CO[CO<br/>Aggregation]
    GCA -->|scorecard| CO
    CO -->|decision| Outcome{Approve /<br/>Revise /<br/>Reject}

    classDef core fill:#fff3e0,stroke:#e65100,stroke-width:2px;
    classDef gov fill:#fce4ec,stroke:#880e4f,stroke-width:2px;
    classDef integration fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px;
    classDef outcome fill:#e1f5ff,stroke:#0277bd,stroke-width:2px;
    class RC,BC,BV core;
    class GCA gov;
    class CO integration;
    class Outcome outcome;

Success Criteria

  • All six axes score 3/5 or higher, or have explicit mitigation plans
  • Session completes within 90 minutes including buffer
  • Written decision record is published within 24 hours
  • Fewer than 2 design-level surprises emerge during implementation

Anti-Patterns to Avoid

Common mistakes

  • Skipping the Find stage -- leads to rediscovery and wasted debate
  • Letting BC also run critique -- authors cannot critique their own work objectively
  • No scoring rubric -- makes "approve/reject" subjective and contentious
  • Open-ended duration -- design reviews expand to fill all available time

Scaling Considerations

For teams under 6 people, one person may hold both BV and GCA roles. Above 10 people, add a dedicated System Integration Architect (SIA) for cross-system designs. Above 20 people, split into domain-specific review teams with a federated governance model.

Template 2: Incident Response Team

Purpose

Coordinate response during and after a production incident. Runs in two phases: live response (minutes) and post-incident (days).

Persona Composition

Persona Phase Role
Incident Commander (IC) Live Coordinates response, owns timeline
Research Crafter (RC) Both Gathers telemetry, prior incidents
Blueprint Crafter (BC) Live Proposes mitigation actions
Documentation Evangelist (DE) Post Writes the post-mortem
Blueprint Validator (BV) Post Reviews root cause analysis
Governance Compliance Auditor (GCA) Post Compliance/customer-impact review

Stage Sequence

Live Response (0-120 minutes)

IC declares severity, assigns roles, opens a response channel. RC runs continuous information gathering. BC proposes mitigations in 5-minute intervals. IC approves and tracks actions.

Stabilization (2-24 hours)

Team confirms mitigation holds. RC captures all telemetry and artifacts. IC closes the incident.

Post-Mortem (1-5 days)

DE drafts a blameless post-mortem. BV validates the root cause. GCA reviews for customer disclosure and compliance obligations. Team holds a retrospective.

Mermaid Diagram

flowchart TD
    Alert([Alert Fires]) --> IC1[IC: Declare Severity]
    IC1 --> RC1[RC: Gather Telemetry]
    IC1 --> BC1[BC: Propose Mitigations]
    RC1 --> BC1
    BC1 --> IC2{IC: Approve?}
    IC2 -->|Yes| Action[Execute Mitigation]
    IC2 -->|No| BC1
    Action --> Check{Resolved?}
    Check -->|No| RC1
    Check -->|Yes| Close[IC: Close Incident]
    Close --> DE1[DE: Draft Post-Mortem]
    DE1 --> BV1[BV: Validate Root Cause]
    BV1 --> GCA1[GCA: Compliance Review]
    GCA1 --> Publish[Publish Post-Mortem]

    classDef live fill:#ffebee,stroke:#b71c1c,stroke-width:2px;
    classDef post fill:#e8eaf6,stroke:#283593,stroke-width:2px;
    classDef outcome fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    class Alert,IC1,RC1,BC1,IC2,Action,Check live;
    class Close,DE1,BV1,GCA1,Publish post;

Handoff Protocol

During live response, IC owns every handoff -- no persona acts without IC acknowledgment. In post-mortem, handoffs are asynchronous with 24-hour SLAs between stages.

Success Criteria

  • Time-to-mitigation beats your team's MTTR target
  • Post-mortem is published within 5 business days
  • No repeat of the same root cause within 90 days
  • All compliance notifications meet regulatory deadlines

Anti-Patterns

Avoid these during live response

  • Multiple ICs -- one commander at a time, always
  • Debating root cause during response -- focus on mitigation first
  • No timeline recording -- you will regret it during post-mortem
  • Skipping the blameless retro -- blame kills future reporting

Scaling Considerations

Above 15 engineers, designate an on-call rotation for IC separate from on-call engineering. Above 50, add a dedicated Communications Lead to handle customer messaging during incidents.

Template 3: Architecture Kickoff Team

Purpose

Establish architecture, conventions, and initial personas for a new project or major initiative in 2-5 working days.

Persona Composition

Persona Role
Research Crafter (RC) Domain discovery, constraint gathering
Blueprint Crafter (BC) Architecture authoring
Blueprint Validator (BV) Design critique
Documentation Evangelist (DE) ADR drafting, onboarding docs
System Integration Architect (SIA) Cross-system concerns
Governance Compliance Auditor (GCA) Standards alignment

Stage Sequence

Day 1 -- Discover (Find)

RC produces a domain brief: users, jobs-to-be-done, constraints, non-goals. SIA identifies upstream/downstream systems.

Day 2-3 -- Design (Create)

BC drafts the C4 context + container diagrams, chooses core patterns, lists alternatives. DE starts the ADR template.

Day 4 -- Review (Critique)

BV scores the design on clarity, feasibility, testability. GCA checks governance alignment. Team holds a one-hour synchronous review.

Day 5 -- Publish

DE finalizes ADRs, onboarding doc, and persona roster. BC publishes the kickoff decision record.

Mermaid Diagram

flowchart LR
    D1[Day 1<br/>Discover] --> D23[Day 2-3<br/>Design]
    D23 --> D4[Day 4<br/>Review]
    D4 --> D5[Day 5<br/>Publish]

    subgraph D1Personas["Find Stage"]
        RC[RC]
        SIA[SIA]
    end
    subgraph D23Personas["Create Stage"]
        BC[BC]
        DE[DE]
    end
    subgraph D4Personas["Critique Stage"]
        BV[BV]
        GCA[GCA]
    end

    D1 -.runs.-> D1Personas
    D23 -.runs.-> D23Personas
    D4 -.runs.-> D4Personas

    classDef core fill:#fff3e0,stroke:#e65100;
    classDef gov fill:#fce4ec,stroke:#880e4f;
    classDef integration fill:#e8f5e9,stroke:#1b5e20;
    class RC,BC,BV,DE core;
    class GCA gov;
    class SIA integration;

Success Criteria

  • Architecture documented in ADR format before Day 5 ends
  • 3-5 personas chosen for ongoing project use
  • Quality gates established with concrete thresholds
  • All team members can explain the architecture in 2 minutes

Anti-Patterns

Kickoff pitfalls

  • Extending past 5 days -- kickoffs that drag lose urgency and alignment
  • Skipping the Find stage -- produces designs divorced from user needs
  • No ADRs -- future engineers will not know why decisions were made
  • Persona roster chosen in Day 1 -- you do not know what you need yet

Scaling Considerations

For 3-person projects, compress to 3 days with RC and BC as the same person. For 10+ person projects, extend to 10 days and add a SAFe Metrics Crafter (SMC) for program-increment alignment.

Template 4: Documentation Sprint Team

Purpose

Produce or refresh a significant documentation deliverable (book chapter, tutorial series, reference guide) in a focused 1-2 week sprint.

Persona Composition

Stage Sequence

Phase 1: Outline (Days 1-2)

DE sets style guide and success criteria. BC produces chapter outlines with learning objectives and section skeletons. SMEs review outlines for accuracy and scope.

Phase 2: Draft (Days 3-7)

RC gathers examples, code snippets, diagrams. BC (or SMEs) write chapter drafts against outlines. DE reviews each draft for voice and structure.

Phase 3: Review (Days 8-10)

BV validates technical correctness of all code examples. SMEs do a final accuracy pass. DE finalizes cross-references and integrates the deliverable into the docs site.

Handoff Protocol

Each chapter moves through states: Outlined -> Drafting -> Drafted -> Reviewed -> Published. Maintain a shared board; state transitions require the named owner's sign-off.

Success Criteria

  • All chapters reach "Published" state by sprint end
  • Code examples execute successfully in a clean environment
  • Cross-references validate with validate-docs command
  • Reader feedback collected within 30 days of publication

Anti-Patterns

Documentation sprint mistakes

  • Writing before outlining -- guarantees rework
  • One author per chapter with no review -- voice drifts, errors compound
  • No code validation -- broken examples erode trust fast
  • Publishing without a distribution plan -- content nobody finds is wasted

Scaling Considerations

For teams over 8 people, split the sprint into parallel streams by chapter cluster. Each cluster needs its own DE. See Contributing to Books for book-specific workflow.

Template 5: Compliance Audit Team

Purpose

Prepare for or execute a formal compliance audit (SOC 2, ISO 27001, EU AI Act, HIPAA, etc.) using FCC's compliance modules.

Persona Composition

Stage Sequence

Scoping (Week 1)

GCA defines scope: regulations in play, systems in scope, control families, evidence expected. Uses the requirement registry (256+ EU AI Act, 29 NIST AI RMF).

Evidence Gathering (Weeks 2-4)

RC collects existing logs, policies, architecture docs, test results. DE drafts missing artifacts. DGS ensures data-handling controls have evidence.

Control Testing (Week 5)

BV runs control tests per the compliance auditor. GCA reviews findings and assigns remediation owners.

Remediation & Report (Weeks 6-8)

Team closes gaps. GCA produces final audit report with evidence graph. DE publishes summary for leadership.

Success Criteria

  • 100% of in-scope requirements have evidence
  • Zero critical findings remain open at audit time
  • Evidence graph is complete and traversable
  • Audit report delivered on target date

Anti-Patterns

Compliance team mistakes

  • Starting evidence gathering without scoping -- wastes effort on out-of-scope work
  • Treating it as a one-time event -- compliance is continuous
  • No separation of duties -- same person drafting and testing controls
  • Manual evidence collection only -- use the compliance pipeline to automate

Scaling Considerations

For teams handling multiple simultaneous audits, run a dedicated compliance squad with its own GCA and DGS. Use the compliance pipeline for automated re-audits on code changes.

Template 6: Cross-Team Handoff Team

Purpose

Move a project, feature, or system from one team's ownership to another with minimal knowledge loss.

Persona Composition

Stage Sequence

Week 1 -- Inventory

CO convenes both leads. RC interviews outgoing team to extract implicit knowledge (runbooks, war stories, sharp edges). Inventory all artifacts: code, docs, dashboards, runbooks, alerts, on-call rotations.

Week 2 -- Document

DE converts interview notes and inventory into handoff package: architecture diagram, runbook, onboarding guide, known-issues list, contact escalation path.

Week 3 -- Shadow

Incoming team shadows outgoing team in all regular ceremonies (standups, on-call, releases). BV validates handoff package completeness by asking incoming engineers to execute key runbooks unassisted.

Week 4 -- Transition

Incoming team leads all ceremonies with outgoing team available for questions. CO closes the handoff with a signed acceptance document.

Success Criteria

  • Incoming team runs the system independently in Week 4
  • Zero production incidents caused by knowledge gaps in Weeks 5-8
  • Handoff package is findable and maintained post-transition
  • Both leads sign acceptance document

Anti-Patterns

Handoff failures

  • No shadow period -- documents alone never transfer tacit knowledge
  • Outgoing team fully released on Week 1 -- nobody to answer questions
  • No acceptance criteria -- handoffs linger for months
  • Skipping the inventory -- surprises emerge for years

Scaling Considerations

For larger handoffs (entire product line, multiple services), extend to 8-12 weeks with phased acceptance criteria. Consider using the federation module to track cross-team ownership boundaries.

Template 7: Roadmap Planning Team

Purpose

Produce a 6-12 month roadmap with stakeholder buy-in, capacity-validated, and risk-assessed.

Persona Composition

Stage Sequence

Discovery (Week 1)

RC gathers inputs: customer requests, strategic goals, tech debt backlog, compliance requirements. SMC models available capacity.

Drafting (Week 2)

BC produces roadmap v1 with themes, objectives, and proposed sequencing. SMC validates capacity allocation.

Review (Week 3)

BV critiques feasibility, dependencies, risks. CO facilitates stakeholder review sessions.

Publication (Week 4)

BC publishes finalized roadmap with revision log. CO establishes monthly check-in cadence for drift monitoring.

Success Criteria

  • Roadmap publishes on target date
  • Capacity allocation sums to 100% with 15% buffer
  • Three or fewer stakeholders raise blocking objections at review
  • Roadmap tracks within 20% of plan at 6-month checkpoint

Anti-Patterns

Roadmap mistakes

  • Planning to 100% capacity -- guarantees misses from normal variance
  • No tech debt line item -- debt compounds into crises
  • Roadmap as commitment -- treat it as a plan, revise quarterly
  • Skipping stakeholder alignment -- roadmaps without buy-in fail silently

Scaling Considerations

For organizations running SAFe, align the workflow with Program Increment planning. Above 50 engineers, run parallel roadmap tracks per tribe with a cross-tribe synthesis step.

Choosing the Right Template

flowchart TD
    Need([Team need]) --> Q1{One-time<br/>or recurring?}
    Q1 -->|One-time| Q2{Duration?}
    Q1 -->|Recurring| Q3{Cadence?}

    Q2 -->|1 week| Kickoff[Architecture Kickoff]
    Q2 -->|2+ weeks| Doc[Documentation Sprint]
    Q2 -->|4+ weeks| Handoff[Cross-Team Handoff]

    Q3 -->|Per design| Design[Design Review]
    Q3 -->|On incident| IR[Incident Response]
    Q3 -->|Annual/Quarterly| Audit[Compliance Audit]
    Q3 -->|Quarterly| Roadmap[Roadmap Planning]

    classDef decision fill:#fff9c4,stroke:#f57f17;
    classDef template fill:#c8e6c9,stroke:#2e7d32;
    class Q1,Q2,Q3 decision;
    class Kickoff,Doc,Handoff,Design,IR,Audit,Roadmap template;

Next Steps