Agents In The Team

Agents in the Team

AI coding and ops agents now take tickets directly from issue trackers: Linear delegates issues to agents, Jira work items can be handed to Rovo and partner agents, and GitHub issues can be assigned to Copilot. The agent opens a pull request; a human still has to decide whether it is right. That moves the bottleneck from writing code to reviewing it, and it moves the delivery manager's job from assigning people to deciding which work an agent may take, how it must be specified, who is accountable, and how to see quality slipping early.

The agent treats this as a delivery system, not a tooling choice: a delegation policy with hard blocks, agent-ready tickets, named human accountability, a review-capacity gate, metrics split by author type, security controls, and a phased rollout. Two stdlib tools do the arithmetic.

When to use

• Deciding which backlog items an agent may take, and writing that down as policy
• Rewriting tickets so an agent can execute them without guessing
• Sprint planning with agents: will reviewers keep up?
• Monthly review: are agent PRs holding quality vs human PRs, and vs the DORA metrics?
• Designing access, secrets and prompt-injection controls for agents on trackers and repos
• Rolling agents out from pilot to multiple teams

When NOT to use: choosing or evaluating an AI coding tool itself (vendor evaluation); building an agent (engineering agent-design skills); individual developers using an AI assistant in their editor with no ticket delegation (normal code review applies).

Clarify First

Before producing a policy or plan, confirm these inputs. If any is unknown or vague, ASK - do not assume:

• Which agents and trackers - which agent(s), on which tracker and repos, with what identity (drives access controls and which vendor safeguards exist)
• Reviewer capacity - named reviewers and realistic review hours per sprint (drives the capacity gate)
• Risk areas - what the team owns that is sensitive: auth, payments, personal data, infra (drives hard blocks)
• Baseline - do you have pre-agent delivery metrics? (without one, instability cannot be attributed)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

# Sprint planning: score tickets, check review capacity (exit 2 = over capacity or policy breach)
python3 project-management/execution/agents-in-the-team/scripts/agent_delegation_scorer.py \
  --input backlog.json

# Monthly: delivery metrics split human vs agent, DORA split, optional regression gate
python3 project-management/execution/agents-in-the-team/scripts/agent_delivery_metrics.py \
  --input records.json --gate --tolerance 0.05

Tools Overview

Both support --format markdown (default) or --format json (wrapped as {"schema", "generated_at", "data"} per SHARED_OUTPUT_SCHEMA.md) and --output <file>.

Exit code contract [PROVEN]

Workflow

Step 1 - Set the delegation policy [RECOMMENDED]

Score every candidate ticket on five factors (clarity, context, risk, blast radius, verifiability) plus type fit:

Hard blocks (score irrelevant): auth, payments, secrets, personal data, IAM, production data migrations, crypto, incident response, architecture decisions. Relax one only deliberately, with security sign-off, once your own metrics justify it. Write the policy with assets/delegation_policy_template.md. Factor weights and calibration: references/delegation-and-accountability.md.

Step 2 - Write agent-ready tickets

Use assets/agent_ticket_template.md. An agent reads only the ticket and what it can reach:

1. Outcome in one or two sentences, then 2+ checkable acceptance criteria
2. Context: paths to start from, a link to an existing example of the pattern
3. Constraints: what not to touch, no new dependencies, scope ceiling (one PR, small diff)
4. Named accountable owner and reviewer
5. No secrets, tokens or customer data - ticket text is input to the agent; treat it like code
6. Bugs: a reproduction (steps, input, expected vs actual)

Step 3 - Keep humans accountable [PROVEN]

The Scrum Guide Expansion Pack's "AI and Scrum" expansion (v2026.1) states that "humans remain accountable for decisions and results", that "AI may recommend, but humans decide", and that "every piece of AI-generated code must be reviewed with the same rigor as if a teammate wrote it"; it asks teams to strengthen, not relax, the Definition of Output Done and to flag AI-generated work items. Trackers model the same idea: Linear's docs say assigning an issue to an agent delegates it "while the human teammate remains the primary assignee and owner".

Team rules: every agent ticket has a named human owner; agent PRs use the same branch protection and review as human PRs; the agent never approves or merges; where supported, the delegating person is not the only approver; agent work is labelled and shown at Sprint Review. Tracker-by-tracker detail (as of September 2026): references/delegation-and-accountability.md.

Step 4 - Plan review capacity

Review hours are the constraint. Before committing the sprint, run agent_delegation_scorer.py. It estimates review hours per planned agent ticket (points, risk multiplier, rework allowance) and compares the total with reviewer hours x max utilization. The defaults (0.5 h base, 0.5 h/point, 30% rework allowance, 80% utilization) are planning assumptions; replace them with your measured review rework rate and reviewer minutes per PR after two sprints. When the gate fails, cut the plan, not the review. Formula and tuning: references/metrics-and-capacity.md.

Step 5 - Measure by author type

Run agent_delivery_metrics.py monthly (or per sprint). DORA's 2025 report found AI adoption positively related to throughput and product performance but still negatively related to software delivery stability, and describes AI as an amplifier of existing strengths and weaknesses. So watch stability first:

• DORA instability and recovery (dora.dev definitions): change fail rate, deployment rework rate, failed deployment recovery time - split by deployments with vs without agent changes
• Agent-specific: PR acceptance rate, review rework rate, post-merge rework rate, time to first review, reviewer minutes per PR, escaped defects per 10 merged PRs

Cohorts under 10 merged PRs are flagged as directional. Set the --tolerance in the rollout plan; a breach narrows the bands. Do not measure lines of code, PR counts or agent "utilization" as productivity.