Entain AI Pod Operating Model

Pod Identity & Intake Framework

Every AI Pod must complete the Gold Standard Intake Pack before kick-off. The intake pack covers 9 sections that define the pod's identity, team, goals, metrics, tooling, and ways of working.

1. Pod Identity

Core information that identifies the pod and its mission.

• Pod Name — a short, memorable identifier for the pod
• Pod Type — the category of work the pod focuses on
• Goal — the primary objective the pod aims to achieve
• Initiative Name — the broader initiative this pod supports
• Planned Start Date — when the pod begins work
• Planned End Date / Duration — target completion or time-box

2. Team Composition

The pod team structure: 2–5 makers plus a sponsor.

• Product Maker — owns the "what" and "why"
• Engineer Maker — owns the "how"
• Quality Maker — owns the "trust"
• Sponsor — director-level, owns the outcome and clears escalations
• Typical pod: 3 makers. Scale to 4–5 only when complexity demands it.

3. Key Attributes & Hypothesis

What the pod is focused on and what it aims to prove.

• Key Attributes — describing the pod's focus area and domain
• Hypothesis — the specific assumption the pod is testing or validating

4. Baseline Metrics

Quantitative measures captured before kick-off to track improvement.

• Speed baseline — cycle time from In Progress to Done
• Quality baseline — defect rate and rework percentage
• Handoffs — number of handoffs per work item
• WIP — work in progress count at any point
• Blocked time — duration items spend in blocked state
• Flow efficiency — active time vs total time ratio
• Pod-specific KPIs — metrics unique to the pod's domain
• Measurement approach — Jira timestamps, telemetry, tool logs

5. Risks & Dependencies

Known blockers and external factors that could affect delivery.

• Known Risks — identified threats to the pod's success
• External Dependencies — teams, systems, or approvals the pod relies on

6. AI Tooling Setup

The AI tools and access required for the pod to operate effectively.

• Kiro IDE — the primary AI-powered development environment
• AI code generation — automated code authoring assistance
• AI test generation — automated test creation and coverage
• AI documentation — automated documentation generation
• Automated code review — AI-assisted code review tooling
• Licences / access sorted — all tools provisioned and accessible
• Engineers trained — team members onboarded to AI tooling
• AI adoption target — measurable goal for AI tool usage

7. Ways of Working

Cadences, Kanban board design, and operational standards for the pod.

• Morning Sync — Daily (5–10 min, blockers and flow only)
• Board Walk — 2–3×/week (10 min, walk the Kanban board)
• Weekly Reflection + Agent Review — Friday (30 min)
• Mission Check-in — Fortnightly (30 min, KPI progress to stakeholders)
• Mission Recalibration — Monthly (30 min, pivot/persist/stop)
• Team Health Pulse — Monthly (async, 3 questions)
• Kanban board with WIP limits (Ready: 5, Discovery: 2, In Progress: 3, In Review: 2)
• No sprints, no velocity, no story points — measure cycle time and throughput

8. Key Dates

Critical milestones that anchor the pod's timeline.

• Baseline captured — metrics recorded before work begins
• Kick-off — official pod start date
• First learning review — initial fortnightly review
• First monthly data point — first full month of metrics
• Leadership review point — scheduled leadership check-in

9. Additional Context

Supplementary information relevant to the pod's setup.

• Scope notes — boundaries and clarifications on what's in/out of scope
• Stakeholder comms — communication plan and key contacts
• Anything else — additional context the pod needs to capture

Team Composition & Makers

A pod is 2–5 makers, not roles. The difference is T-shaped ownership. The typical pod is 3 makers (Product, Engineer, Quality). Pods scale to 4–5 only when complexity demands it or for deliberate senior/junior pairing. A pod above 5 is a squad — split it.

Six Maker Dimensions

Every maker should embody these six dimensions. AI Fluency is non-negotiable — without it, the AI-native pod model fails.

• AI Fluency (non-negotiable) — Can operate with at least one AI agent, score output, and articulate when to trust and when to override
• Cross-Functional Versatility — Contributes beyond their specialism (T-shaped)
• Customer & Value Awareness — Understands the user and business impact
• Craft — Deep expertise in their primary domain
• Technical Curiosity — Explores new tools, techniques, and approaches
• Agency & Entrepreneurship — Takes ownership and drives outcomes

Pod Types

Baseline Metrics & KPIs

Every pod must capture baseline measurements for six core metrics before kick-off. These baselines provide the reference point against which improvement is tracked throughout the pod's lifecycle.

Ways of Working

Every recurring meeting must pass one test: "Does this create a decision, unblock someone, or surface a risk?" If it doesn't, it's waste. Kill it. A small pod of 2–5 makers with AI agents doesn't need the ceremony overhead designed for 10-person squads. You need cadence, not ceremony.

Cadences That Live

Total meeting time: ~2.5 hrs/week.

The Kanban Board

Swimlanes: Features (mission deliverables), Enablers (tech debt, tooling, agent tuning), Bugs (production issues). Anything stuck in a column for >3 days is a signal — surface it at the Board Walk.

Flow Metrics (Not Velocity)

Weekly Rhythm

Times are illustrative — each pod sets its own schedule. What matters is the pattern, not the clock.

• Monday — Morning Sync (5–10 min). Makers pull from "Ready" and build.
• Tuesday — Morning Sync (5 min). Board Walk (10 min). Heads-down work.
• Wednesday — Morning Sync (5 min). Heads-down work. Mid-week push.
• Thursday — Morning Sync (5 min). Board Walk (10 min). Ship anything that's ready.
• Friday — Morning Sync (5 min). Weekly Reflection + Agent Review (30 min). Update metrics. Product Maker grooms "Ready" for next week.
• Fortnightly — Mission Check-in with stakeholders (30 min).
• Monthly — Mission Recalibration (30 min). Team Health Pulse (async, 3 questions).

Story Quality Standards

High-quality stories are the foundation of predictable delivery. These standards ensure every story entering a sprint is well-defined, estimable, and testable — reducing rework and keeping the pod focused on delivering value.

Epic Structure

Every Epic must have a clear summary, description, and goal. Epics should contain 5–10 child stories (target ratio 1:5 to 1:10). No orphaned stories — every story must belong to a parent Epic. No empty Epics — every Epic must have at least one child story. Epic priorities must be assigned.

INVEST Principles

Every user story must satisfy all six INVEST criteria before entering a sprint:

Acceptance Criteria Standards

Acceptance criteria define the conditions that must be met for a story to be considered complete. Two formats are supported:

• Given/When/Then (Gherkin) — Structured behavioural format: Given a precondition, When an action occurs, Then an expected outcome results
• EARS (Easy Approach to Requirements Syntax) — Structured format: "WHEN [trigger] THE system SHALL [behaviour]"

Be consistent within a single document — don't mix formats. Every story must have at least 2 acceptance criteria covering the happy path and at least one error/edge case scenario. Each criterion must be independently testable with no vague language.

Definition of Ready

A story is not ready for development unless it meets all of the following criteria:

• ☐ Clear description with user story format
• ☐ Acceptance criteria (minimum 2, covering happy + error paths)
• ☐ Story points assigned (1–13 range)
• ☐ Priority set
• ☐ Parent Epic assigned
• ☐ Dependencies identified and documented
• ☐ No unresolved open questions

Definition of Done

A story is not done unless it meets all of the following criteria:

• ☐ All acceptance criteria are met
• ☐ Code review completed
• ☐ Tests written and passing
• ☐ Documentation updated (if applicable)
• ☐ No regressions introduced
• ☐ Properly transitioned through workflow states

Issue Type Categorisation

Use the correct issue type for each piece of work to maintain a clean and meaningful backlog:

• Story — Feature work that delivers user value
• Bug — Defects in existing functionality
• Task — Non-feature work (infrastructure, setup, admin)
• Improvement — Enhancements to existing features

Target distribution: 30–40% Stories, <20% Bugs, <10% Technical Debt. Tag technical debt explicitly with a "tech-debt" label. Tag dependencies using issue links, not just labels.

Priority Guidelines

Kiro Spec-Driven SDLC

Kiro transforms natural language intent into structured, traceable development artefacts through a three-phase spec-driven workflow. Each phase produces a versioned markdown file that serves as both documentation and execution plan.

The Three-Phase Flow

Phase 1: Requirements

The requirements phase takes natural language input — a feature description, user request, or problem statement — and produces a structured requirements.md file. Each requirement includes acceptance criteria written in EARS (Easy Approach to Requirements Syntax) notation, ensuring they are unambiguous and testable. The output is a numbered list of requirements with clear "WHEN... THE system SHALL..." conditions.

Phase 2: Design

The design phase analyses the actual codebase alongside the requirements to produce a design.md file. This includes data models, API contracts, component structure, and integration points. The design is grounded in the real project — not abstract architecture — so it reflects existing patterns, libraries, and conventions already in use.

Phase 3: Tasks

The tasks phase generates a tasks.md file containing a numbered, dependency-ordered implementation checklist. Each task is traceable back to specific requirements, creating a clear audit trail from intent to implementation. Tasks are sized for incremental execution and can be worked through sequentially.

Steering Files

Steering files provide persistent project context that Kiro uses across all interactions. Stored in the .kiro/steering/ directory, these markdown files capture conventions, technology stack details, coding standards, and domain knowledge. Kiro automatically loads relevant steering files to maintain consistency across specs and sessions.

Hooks

Hooks are automations triggered by file events within the development environment. They enable workflows like automatic test synchronisation when source files change, documentation updates when APIs are modified, and pre-commit checks that run before code is committed. Hooks reduce manual overhead and enforce quality gates without interrupting flow.

MCP Integration

The Model Context Protocol (MCP) enables Kiro to connect to external tools and data sources via configuration in .kiro/settings/mcp.json. This allows the agent to query AWS documentation, interact with GitHub repositories, access databases, and integrate with other services directly during spec creation and task execution.

Execution Modes

• Autopilot — The agent executes the full task list without pausing after the spec has been reviewed and approved. Ideal for well-defined, low-risk changes where the spec captures all requirements accurately.
• Supervised — The agent asks for approval at each significant action, giving the developer control over every step. Recommended for complex changes, unfamiliar codebases, or high-risk modifications.

Risks & Dependencies

Every pod must identify, assess, and actively manage risks and external dependencies throughout its lifecycle. Documenting these upfront during intake ensures the team is prepared and that mitigation plans are in place before work begins.

Risk Identification & Assessment

Risks are potential events or conditions that could negatively impact the pod's ability to deliver. Each risk should be documented with a structured assessment using the likelihood × impact framework:

Dependency Tracking

External dependencies are factors outside the pod's direct control that could block or delay delivery. Track each dependency with the following structure:

• External Teams — Other teams whose work or decisions the pod depends on (e.g., platform team for infrastructure, security team for approvals)
• External Systems — Third-party services, APIs, or infrastructure the pod relies on (e.g., CI/CD pipelines, cloud services, data platforms)
• Approvals — Sign-offs or governance gates required before the pod can proceed (e.g., architecture review, security review, change advisory board)
• Status Tracking — Each dependency should have a status (Open / In Progress / Resolved) and an expected resolution date

AI Tooling Setup

AI tooling is central to the pod's workflow. Every pod must have the following five standard AI tools provisioned, configured, and accessible before kick-off. Engineers should be trained on each tool and the pod should set a measurable AI adoption target.

Standard AI Tools

Readiness Requirements

• Licences & Access — All five AI tools must be provisioned with active licences. Every engineer on the pod must have individual access configured and verified before kick-off.
• Engineer Training — Each engineer must complete onboarding for the AI tooling stack. This includes hands-on practice with Kiro's spec-driven workflow, code generation prompting, and test generation capabilities.
• AI Adoption Target — The pod must set a measurable adoption target (e.g., "80% of new code authored with AI assistance" or "100% of stories have AI-generated test coverage"). This target is tracked as part of the pod's baseline metrics.

Key Dates

Critical milestones that anchor the pod's timeline. These dates should be agreed during intake and tracked throughout the pod's lifecycle to ensure the team stays on schedule.

Additional Context

Supplementary information that doesn't fit neatly into other sections but is important for the pod's setup and ongoing operation. Capture anything here that the team needs to reference.

Scope Notes

Document the boundaries of the pod's work. Clearly state what is in scope and what is explicitly out of scope. This prevents scope creep and ensures the team stays focused on the agreed goal. Include any assumptions that underpin the scope definition.

Stakeholder Communications

Define the communication plan for keeping stakeholders informed. This should cover who the key stakeholders are, how often they receive updates, what format updates take (email, Slack, demo invites), and who is responsible for stakeholder communication (typically the Product Manager).

Any Other Business

A catch-all for additional context the pod needs to capture. This might include technical constraints, regulatory requirements, integration notes, migration considerations, or any other information that the team should be aware of but doesn't belong in a specific section above.

Branding Reference

This section documents the brand palette, typography, and design tokens used throughout this site. All values are defined as CSS custom properties on :root and referenced by every component for consistency.

Colour Palette

Typography

Font Family: 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif

Type Scale

Line Height: var(--line-height-base): 1.6 — used across all body text for comfortable readability.