Team Capacity Model — Ghasi Melmastoon
Companion: Roadmap Index · jira-epic-based-sprint-ruleset.md · jira-sprint-distribution-rules.md · service-readiness-gates.md
This document defines squads, ownership, headcount assumptions, and effective capacity for sprint planning. It is the single source for the planner — human or commands/jira-sprint-plan.md — when computing what "100 % of a sprint" actually means.
It is not an org chart. It is an operating model: roles exist whether or not they are filled by named people, and AI agents count as fractional capacity where they own a defined scope.
1. Squads (logical, not necessarily 1:1 with reporting lines)
Six squads, one platform team, one quality/release function, one product/UX function. Sized for R1; scales by adding seats inside an existing squad before splitting a squad.
1.1 Squads and primary components
| Squad | Mission | Primary components | R1 size | R2 size |
|---|---|---|---|---|
| Reservations & Inventory | Booking flow truth: searches, holds, confirmations, cancellations, calendar correctness. | reservation-service, inventory-service, pricing-service, tax-service, bff-tenant-booking-service (lead) | 1 EM + 4 SWE + 1 QA | + 1 SWE |
| Money & Trust | Payments, refunds, payouts, fraud, ledger; lock integration. | payment-gateway-service, lock-integration-service, audit-service, feature-flag-service | 1 EM + 3 SWE + 1 SecEng (shared) | + 1 SWE |
| Operations | Front-desk, housekeeping, maintenance, files, notifications. | housekeeping-service, maintenance-service, notification-service, file-storage-service, staff-service, bff-backoffice-service (lead) | 1 EM + 4 SWE + 1 QA | + 1 SWE + 1 QA |
| Surfaces | Web meta, web tenant booking, desktop back-office, future kiosk + voice. | app-web-meta, app-web-tenant-booking, app-desktop-backoffice, pkg-ui-melmastoon, pkg-i18n | 1 EM + 5 SWE + 1 Designer + 1 QA | + 2 SWE |
| Mobile | Cross-OS staff/guest mobile + offline. | app-mobile, pkg-ui-melmastoon (RN parts), pkg-mobile-runtime | 1 EM + 3 SWE + 1 QA | + 1 SWE |
| AI & Analytics | AI gateway, anomaly detection, embeddings, BigQuery, dashboards. | ai-orchestrator-service, analytics-service, theme-config-service (R2), pkg-ai-runtime | 1 EM + 2 SWE + 1 ML | + 2 SWE + 1 ML |
| Platform & SRE | Monorepo, CI/CD, infra, observability, security baseline, FinOps. | infra-*, pkg-contracts, pkg-event-bus, pkg-observability, pkg-eslint-config, pkg-tsconfig, cross-cutting | 1 EM + 3 SWE/SRE + 1 SecEng (shared) | + 1 SRE |
| QA & Release (function, not squad) | Test infra, contract tests, performance budgets, release captain rotation. | Cross-cutting | 1 lead + embedded QAs above | + 1 lead-engineer |
| Product & UX (function) | PRDs, journeys, design system curation, content. | All | 1 PM + 1 Sr Designer + 1 Researcher | + 1 PM + 1 Designer |
R1 total dev-hands: ~25 SWE + 4 QA + 1 ML + 1 SecEng + 6 EMs/leads + 3 product/design + 4 SRE/Platform = ~44 people, of which ~30 are direct sprint-capacity contributors.
1.2 Cross-cutting roles (shared across squads)
| Role | Scope | Allocation |
|---|---|---|
| Security Engineer | Reviews threat models, Money & Trust + Platform & SRE; pen-test triage; KMS/Secret Manager governance. | 1 FTE shared across all squads. |
| Release Captain | Rotates weekly; owns the release train, deployment health, post-deploy comms. | 1 weekly rotation seat per squad. |
| On-call Primary / Secondary | Per service-line, weekly rotation. | See §4.2. |
| AI Agent Steward | Owns Cursor/Claude/Copilot rule changes, agent-prompt PR review, evaluates failure modes. | 0.5 FTE inside Platform & SRE. |
2. Ownership matrix (component → squad)
The Jira component list in docs/standards/JIRA_PROJECT_SETUP.md §3 maps 1:1 to a squad below. Every component has exactly one owning squad (single accountability) and may have one or more collaborating squads (joint design, no joint accountability).
| Component | Owning squad | Collaborating squads |
|---|---|---|
reservation-service | Reservations & Inventory | Money & Trust (holds + payment intent), Surfaces (BFF contracts) |
inventory-service | Reservations & Inventory | Operations (housekeeping turns) |
pricing-service | Reservations & Inventory | AI & Analytics (forecasted demand) |
payment-gateway-service | Money & Trust | Reservations & Inventory |
lock-integration-service | Money & Trust | Operations |
audit-service | Money & Trust | All |
housekeeping-service | Operations | Reservations & Inventory |
maintenance-service | Operations | Operations + Surfaces |
notification-service | Operations | All |
file-storage-service | Operations | Surfaces (uploads) |
staff-service | Operations | All (RBAC) |
tax-service | Reservations & Inventory | Money & Trust |
feature-flag-service | Money & Trust | Platform & SRE |
theme-config-service | AI & Analytics (R2; Surfaces in R1) | Surfaces |
analytics-service | AI & Analytics | All |
ai-orchestrator-service | AI & Analytics | Operations, Money & Trust |
bff-consumer-service | Surfaces | Reservations & Inventory |
bff-tenant-booking-service | Reservations & Inventory | Surfaces |
bff-backoffice-service | Operations | Surfaces |
app-web-meta | Surfaces | — |
app-web-tenant-booking | Surfaces | Reservations & Inventory |
app-desktop-backoffice | Surfaces | Operations |
app-mobile | Mobile | Operations, Surfaces |
pkg-ui-melmastoon | Surfaces | Mobile |
pkg-i18n, pkg-tokens, pkg-icons | Surfaces | All |
pkg-contracts, pkg-event-bus | Platform & SRE | All |
pkg-observability, pkg-eslint-config, pkg-tsconfig | Platform & SRE | All |
pkg-ai-runtime | AI & Analytics | Mobile, Surfaces |
pkg-mobile-runtime | Mobile | Surfaces |
infra-cloud-run, infra-cloud-sql, infra-pubsub, infra-redis, infra-secret-manager, infra-cloud-armor, infra-observability | Platform & SRE | — |
cross-cutting | Platform & SRE | All |
If the matrix shows a component with zero owning squad, that is a P0 staffing gap — flag it during this document's review.
3. Headcount staging
R1 starts with the headcount in §1.1 and grows along the curve below. A new hire's effective capacity is 50 % for sprint 1, 75 % for sprint 2, 100 % from sprint 3.
| Wave | Sprint range | Total dev-hands target | Hiring focus |
|---|---|---|---|
| R1 | S01–S12 | 30 → 32 | Reservations & Inventory + Mobile (offline) |
| R2 | S13–S24 | 32 → 42 | AI & Analytics, Surfaces (chain switcher), SRE (multi-region) |
| R3 | S25+ | 42 → 50+ | White-label PMs, Reseller squad (new), Voice/kiosk specialists |
Hiring tickets live in cross-cutting Tasks with label org:hiring and are not counted against sprint capacity.
4. Effective capacity model
4.1 Engineering focus factor
A 2-week sprint = 10 working days = 10 nominal dev-days per engineer.
The focus factor translates nominal days into effective dev-days that can be committed against backlog:
effective_days = nominal_days × focus_factor
| Role | Default focus factor | Notes |
|---|---|---|
| Senior SWE (no on-call) | 0.65 | 35 % overhead for code review, design, refinement, support, comms. |
| Senior SWE (on-call week) | 0.40 (week 1), 0.60 (week 2) | Page handling + recovery. |
| Mid SWE | 0.60 | More mentoring received, slightly less effective. |
| Junior SWE / new hire | 0.40 → 0.60 over first 6 sprints | Ramp curve. |
| QA | 0.65 | Same overhead pattern, plus test infra. |
| Designer | 0.50 | Significant time on research + critique. |
| EM (engineering manager) | 0.20 | Should not be on hands-on critical path. |
| ML engineer | 0.55 | Long experiments + training cycles. |
| SRE | 0.50 | Significant on-call + incident time. |
| AI agent (e.g., dev-pipeline runs) | 0.10–0.30 (per active scope) | Counted only when the agent owns end-to-end story execution under HITL approval. |
4.2 On-call rotations
| Service line | Primary rotation | Secondary | Cadence |
|---|---|---|---|
| Reservations & Inventory | 1 of squad's 4 SWE | EM | Weekly |
| Money & Trust | 1 of squad's 3 SWE | SecEng | Weekly |
| Operations | 1 of squad's 4 SWE | EM | Weekly |
| Surfaces | 1 of squad's 5 SWE | EM | Weekly (lighter pages) |
| Mobile | 1 of squad's 3 SWE | EM | Weekly |
| Platform & SRE | 1 SRE | 1 SRE | Weekly (24×7) |
| AI & Analytics | 1 of squad's 2 SWE | ML eng | Weekly (bus hours) |
Pages > 5 in a week force an SRE-led incident review.
4.3 Worked example — Reservations & Inventory squad capacity (R1, sprint 5)
| Engineer | Role | On-call this sprint? | Nominal days | Focus factor | Effective days |
|---|---|---|---|---|---|
| EM | EM | — | 10 | 0.20 | 2.0 |
| Sr SWE A | Sr SWE | Yes (week 1) | 10 | 0.40 / 0.60 avg = 0.50 | 5.0 |
| Sr SWE B | Sr SWE | — | 10 | 0.65 | 6.5 |
| Mid SWE C | Mid SWE | — | 10 | 0.60 | 6.0 |
| Mid SWE D | Mid SWE | — | 10 | 0.60 | 6.0 |
| QA | QA | — | 10 | 0.65 | 6.5 |
| Squad effective capacity | 60 | 32 dev-days |
At the project's sizing convention (S=2, M=5, L=8 points; 1 point ≈ 1 dev-day), this squad commits ~32 points in sprint 5.
5. AI-agent capacity accounting
AI agents (commands/dev-pipeline.md, commands/scaffold-service.md, etc.) are treated as fractional capacity contributors when they own end-to-end execution under HITL.
Rules:
- Counted only when an agent is named
Assigneeon a Story or Task that fully autonomously produces a PR a human approves. - Not counted when an agent assists a human (those points stay with the human).
- An agent's effective capacity is bounded by the human reviewer's review capacity (Rule from sprint distribution: review work counts against the human's overhead).
- Treat each "autonomous slice" as 0.5 dev-days of human equivalent (review time, fix-loop, validation), regardless of how fast the agent ran.
This stops the team from over-committing because "AI is fast"; the bottleneck is human review and correctness verification, not generation.
6. Capacity-impacting events
The planner subtracts capacity for each event below, mid-sprint or in advance.
| Event | Capacity impact | Owner of accounting |
|---|---|---|
| Public/regional holiday | -1 nominal day per affected engineer | EM |
| PTO / personal leave | -N nominal days per engineer | Engineer + EM |
| Conference / training | -N nominal days; if knowledge-transfer expected, -0.5 day for the receiving session | EM |
| Hiring loop participation | -1.5 days per loop per interviewer | EM |
| Production incident (P1/P2) | Subtract postmortem time; usually 1–2 person-days for primary | Release captain |
| Re-org / role change | Treat affected engineer as new-hire ramp for 1 sprint | EM |
| Org-wide all-hands / off-site | -0.5 day per engineer | Chief of staff (function) |
Capacity-impacting events are entered in the team's capacity sheet (planning artifact, not a deliverable doc) before sprint planning starts.
7. Skill matrix and bottleneck management
7.1 Cross-skill targets (R1 end)
| Skill cluster | Target coverage |
|---|---|
| NestJS service authoring | ≥ 70 % of SWE |
| Drizzle / migrations | ≥ 50 % |
| Next.js App Router | 100 % of Surfaces squad; ≥ 30 % overall |
| React Native + Expo | 100 % of Mobile squad; ≥ 20 % overall |
| Electron | 100 % of Surfaces squad's desktop sub-team; ≥ 15 % overall |
| Pub/Sub + outbox patterns | ≥ 60 % |
| TanStack Query / Zustand | ≥ 70 % of frontend SWE |
| i18n RTL/LTR | ≥ 80 % of frontend SWE |
| Testcontainers / Pact | ≥ 60 % of SWE; 100 % of QA |
| Playwright + Detox | 100 % of QA + ≥ 30 % of SWE |
| KMS / Secret Manager | ≥ 30 % of SWE; 100 % of Money & Trust |
| Vertex AI / RAG | ≥ 100 % of AI & Analytics; ≥ 10 % overall |
| Observability (OTel, Cloud Logging) | ≥ 80 % of SWE |
| Accessibility (WCAG 2.2 AA) | ≥ 60 % of frontend SWE; 100 % of Designer |
Targets below threshold force a cross-cutting upskilling Task each sprint (≤ 1 day per engineer per sprint).
7.2 Single-points-of-failure (SPOF) register
A skill or component owned by a single engineer is a SPOF. The register must show every SPOF with mitigation status:
| Component / skill | Sole owner | Mitigation | Target date |
|---|---|---|---|
lock-integration-service (vendor-A) | TBD-1 | Pair-rotate 2nd engineer through 3 stories | R1-S08 |
payment-gateway-service 3DS flow | TBD-2 | Cross-train Money & Trust + Reservations | R1-S07 |
| Detox device farm config | TBD-3 | Document in runbook + train Mobile QA | R1-S05 |
| Vertex AI infra | TBD-4 | Pair with SRE | R2-S14 |
The register is reviewed every sprint planning and escalated at every wave checkpoint.
8. Velocity baselines and adjustment
| Wave | Initial velocity baseline | Adjustment trigger |
|---|---|---|
| R1 (S01–S03) | Use focus-factor estimate; no historical baseline yet | After S03, switch to rolling 3-sprint avg |
| R1 (S04+) | Rolling 3-sprint avg of completed points | If avg shifts > 15 %, recalculate focus factors |
| R2+ | Rolling 3-sprint avg, per squad | Same |
Velocity is per squad, not per engineer. Ranking engineers by points is an anti-pattern (see jira-epic-based-sprint-ruleset.md §10).
9. Anti-patterns
- "We'll just hire when we miss the wave" — hiring takes ≥ 2 sprints to net positive; descope first.
- Treating AI agents as 1.0 capacity multipliers — review remains the bottleneck.
- Single-engineer ownership without a SPOF register entry.
- Cross-squad floaters with no home — kills accountability.
- 100 % focus factor assumptions — never realistic.
- Counting EM time at engineer rates — distorts the plan.
- Refusing to update the focus factor when retrospectives show systemic overrun.
10. Cross-references
- jira-epic-based-sprint-ruleset.md
- jira-sprint-distribution-rules.md
- service-readiness-gates.md
- docs/standards/JIRA_PROJECT_SETUP.md
11. Versioning
Same governance as docs/standards/CODING_STANDARDS.md §19. Changes that alter focus factors or squad ownership require sign-off from every affected EM.