Plans, dependencies, RAID and status with AI drafting and humans deciding; evidence travels with the work.
The delivery lead keeps work flowing across people, teams and dependencies: project and program managers, scrum masters and RTEs (release train engineers). AI (artificial intelligence) can draft status, summarize risks and spot dependencies. It cannot own a commitment, and the delivery lead does not approve the artifacts the teams produce. Counts, shares and durations on this page are illustrative.
AI makes teams faster at producing artifacts. The delivery lead's job is to make sure the review, the evidence and the dependencies move at the same speed, or the plan is fiction.
1. At a glance
Field
For the delivery lead
Mandate
Plan and protect the flow of work so that reviewer capacity, control evidence and cross-team dependencies are planned like any other work
Primary outcome
A plan where every AI-delegated item has a reviewer, an evaluation step and an evidence step booked, and every dependency has an owner
First safe win
AI-drafted status and RAID (risks, assumptions, issues, dependencies) summaries from existing tickets, checked against the source before they go out
Biggest failure mode
A plan that counts AI speed-up in velocity but leaves review, evaluation upkeep and AI-generated tech debt off the board
Line: 1st line · Family: Lead · Variants: project or program manager, scrum master, RTE
Variant
What differs
Project or program manager
Owns the plan, budget tracking, the RAID log and milestone reporting across teams; escalates to the sponsor
Scrum master
Serves one team: facilitates events, makes review load visible, protects the team's agreed working rules; owns no delivery commitments of its own
RTE
Facilitates a train of teams: program increment planning, cross-team dependencies, shared risks, readiness evidence for train-level releases
People leadership, performance and the team's delegation decisions sit on the engineering manager track. This page is the flow, dependency and evidence lane.
2. Your journey: first steps to fully adopted
The delivery lead's journey starts with making AI's hidden work visible and ends with plans that run on evidence.
Start here: your first steps
List every AI-delegated item in flight, with the person who reviews it.
Draft status from tickets with the approved assistant, and check every line against its ticket.
Add review, evaluation and evidence steps to the plan as real work items.
Add AI-specific risks to the RAID log, each with a named risk owner.
Fully adopted: how the work runs
Moment in the work
Before AI
Fully adopted (Stage 4–5)
Decision that stays human
Planning an increment
Velocity counts AI speed-up; review is left off the board
Every delegated item has a booked reviewer, an evaluation run and a dated evidence step
Commitments to stakeholders
Mapping dependencies
Found late, in a status meeting
An agent drafts the dependency map from the impact analysis and the catalog; each dependent team confirms it
The sequence: the formatPaymentCutoff extension before the four display changes
Tracking risk
The RAID log is updated by hand before each steering meeting
An agent drafts the weekly RAID summary with ticket links; each risk owner confirms their items
Accepting, escalating or closing a risk
Release readiness
Evidence assembled the night before
The readiness view links each evidence item to the change record as the work completes
Release approval, by the change authority, never the delivery lead
After release
Lessons are lost between projects
Shared planning templates and status prompts live in the catalog, with owners
Moving a date when evidence is missing
What changes for the organization
Before
After
Plans count speed but not review
Review and evidence are booked work
Status figures nobody can trace
Every status line links its ticket
Releases slip at the last step
Evidence lands with the work, increment by increment
In any organization
Small or unregulated: the engineering manager or a team lead covers this seat; a simple board and a risk list replace the program tooling.
What scales: program increment ceremonies and formal readiness views shrink. A human owner for every commitment and risk, human approval of merges and releases, and no customer data in unapproved tools never do.
3. Your decisions
The column "your relationship" uses the decision relationship vocabulary: owner or approver · independent validator or challenger · consulted control partner · evidence recipient · notified. Most delivery-lead decisions are about the plan. The artifacts themselves are approved by their owners.
Decision
Your relationship
Inputs
Escalation
Cannot be delegated
Plan includes review and evidence work
Owner of the plan
Delegated task list, review time per artifact, evidence checklist
Impact analysis, team capacities, shared-asset owners
The sponsor or portfolio board
Yes
RAID log entries and owners
Owner of the log; each risk has its own owner
Team inputs, AI-drafted summaries checked against source
The program sponsor
Yes
Release readiness view
Evidence recipient; the release manager assembles, the change authority approves
Test evidence, approvals, change record status
The release manager
Not yours to approve
Pause a delegated item for capacity
Consulted; the engineering manager decides
Review load against budget
The engineering manager
Not yours alone
Status published to leaders
Owner
AI draft, checked against tickets
The program sponsor
Yes
4. Two kinds of adoption
Kind
What it means for you
Example
How you work with AI
Drafting status, meeting notes, RAID summaries and dependency maps from tickets and documents you are allowed to read
The assistant groups open tickets by blocking dependency; you check each against the ticket
What you plan and facilitate that contains AI
Teams' delegated tasks, evaluation work, review capacity, evidence steps and the tech debt AI-generated code can leave behind
The plan shows two reviewers booked for the generated date-and-time suites, by sprint
5. Your ladder
The adoption ladder describes controls and evidence. For the delivery lead, each stage changes what the plan must hold, not who decides.
Stage
AI use from your seat
Guardrail
Artifact or evidence
Decision relationship
Step-down trigger
0 · Foundations
None
Acceptable use attested; approved tool; ticket access rules respected
Attestation
Owner of your own readiness
Use of an unapproved tool for meeting notes
1 · Personal productivity
Drafts status and minutes from your notes
No restricted data; you apply every edit
Draft status, checked
Owner of what you publish
A published figure is wrong and untraced
2 · Team context
A reviewed status prompt grounded in the team's ticket fields and RAID template
Prompt reviewed like code; source links required
Status with links to tickets
Owner of the status
Summaries lose their source links
3 · Delegated tasks
An agent drafts the weekly RAID summary and dependency list
Every item links its ticket; risk owners confirm their items
RAID summary, confirmed by owners
Owner of the log; each risk owner owns their risk
An owner rejects an AI-drafted risk statement twice
4 · Agentic workflows
Teams run agentic workflows; you plan around them
Plan includes evaluation runs, kill-switch drills, review gates
Plan with evidence steps per workflow
Evidence recipient of readiness
A release is scheduled without its evidence step
5 · Scale and sustain
Shared planning templates and status prompts across trains
Owner and review date on each template
Catalog entries for planning assets
Owner of the shared template
A template drifts from the RAID standard
Human-operated at Stage 5. Commitments to stakeholders, the decision to escalate a risk, and the RAID risk owners stay human. An agent can draft the RAID summary. It never accepts or closes a risk.
6. Priority scenarios
Scenario
Value
Risk tier
Stage
First step
Do not use AI when…
Status from tickets
Less time compiling, more time unblocking
Low
1
Draft from ticket fields only
The status would go out unchecked
RAID summary
Risks visible earlier
Low
3
Each item links its ticket; owners confirm
It would close or downgrade a risk
Dependency map
Cross-team blockers found before planning
Medium
2
Use the impact analysis and catalog as sources
The map replaces asking the dependent team
Planning review capacity
Realistic commitments
Low
1
Use measured review time per artifact
You have no measured data yet; use the illustrative budget and say so
AI-generated tech debt tracking
Duplicates and drift caught early
Medium
2
Track reuse decision records marked "create" and catalog warnings
The tracking would be used to rank individuals
Meeting minutes
Faster write-ups
Low
1
Use only approved meeting tools with recording consent
The meeting discussed personnel or restricted matters
7. The due-date ask from your seat
The organization must show the contractual payment due date the same way on web, mobile, statements and reminder notifications, and the payment cutoff time in the customer's own time zone. Four services change, plus one additive display function in shared-datetime: formatPaymentCutoff(cutoffInstant, customerZone). It only formats; payment-schedule-service alone computes the cutoff and exposes it as an instant. That makes it a dependency problem, which is the delivery lead's material work.
Step
What the delivery lead does
Artifact
Map the dependencies
From the confirmed impact analysis: web, mobile, statement-service and notification-service all depend on the formatPaymentCutoff extension to format the cutoff instant they receive; payment-schedule-service and profile-service do not change
Dependency map with owners
Sequence
The architecture-owned extension and the temporal-domain contract come first; the four display changes follow; statement-service goes last, because issued statements are immutable
Sequenced plan
Book review and evidence
Each delegated test-generation item gets a booked reviewer and an evaluation run; compliance review of the statement wording is a dated item
Plan with evidence steps
Keep the RAID log
Risk: daylight-saving edge case not in the evaluation set (owner: QA lead). Dependency: extension release date (owner: architecture). Assumption: zone fallback label approved by compliance
RAID log
Readiness view
Shows which evidence is in place for the change record; the release manager assembles it, the change authority approves
Readiness view
8. Hand-offs and separation of duties
You give → to whom
You receive ← from whom
You challenge
You are notified of
Sequenced plan → engineering managers and teams
Impact analysis ← the architect and business analyst
Plans that count AI speed-up but no review time
Release approvals
RAID summary → the program sponsor
Risk confirmations ← each risk owner
Risks closed because an agent summary said so
Kill-switch use or incidents in the train
Readiness view → the release manager
Evaluation and test status ← QA (quality assurance) engineers
Dates that skip the evidence step
Exceptions affecting the plan
Capacity risks → the engineering manager
Asset release dates ← shared-asset owners
Duplicate work hidden as new scope
Provider or model changes affecting a planned release
Separation of duties. The delivery lead tracks evidence but approves none of it. The reviewer of a generated artifact, the change authority and each risk owner stay separate people.
9. Evidence and records
Evidence
Produced or consumed
System of record
Retention owner
Plan with review and evidence steps
Produced
Planning tool
The delivery lead
RAID log
Produced
Program workspace
The delivery lead; each risk owner for their entry
Status reports
Produced
Program workspace
Records, per schedule
Readiness view
Produced, from others' evidence
Links to the change record and evidence index
The release manager owns the change record
Dependency map
Produced
Planning tool, linked to the asset catalog
The delivery lead
Meeting minutes with AI drafting
Produced
Approved collaboration tool
Records; check retention rules for recordings
10. Skills and learning path
Level
What the delivery lead learns
Labs
Done when
Foundation
Acceptable use; data classification of tickets and minutes; what an evidence chain is
Your status prompt is reviewed and every line links a ticket
Advanced
Running a train with agentic workflows; planning step-downs
Tabletop: a provider change forces re-evaluation two days before a train release
The plan absorbs the step-down and the release date moves on evidence
11. Measures and incentives
Metric
Definition
Anti-gaming note
Evidence on time
Planned evidence steps done by their date, divided by all planned
Do not drop steps from the plan to raise the rate
Review load against plan
Review hours used against hours booked
A big gap either way means the plan is wrong
Dependency slip
Days a blocking dependency moved, per increment
Read with scope change
Cycle time
Ask to production, per change
Never read without change-failure rate
Create decisions
Reuse decision records marked "create", per increment
A justified create is fine; a rising trend is a catalog signal, not a team penalty
Status accuracy
Status items later corrected
Low corrections can mean nobody checks; sample them
Velocity is not the measure. A higher velocity from AI-generated work, with rework rising, is a worse plan. Report velocity only next to rework rate. See the measure chapter.
12. Cost, capacity and workforce
The delivery lead turns AI's hidden work into planned work. Reviewer capacity is the protected time for people to check AI output, and it belongs on the board.
Hidden work
How to plan it
Illustrative figure
Review of delegated artifacts
A booked reviewer per item, by name
About 20% of team capacity once Stage 3 starts
Evaluation upkeep
A recurring backlog item per delegated task
2 days per quarter per task
Evidence assembly
A planned step before every release
Half a day per release with Stage 3 work
AI-generated tech debt
Clean-up items from reuse warnings and "create" decisions
One item per sprint, reviewed at planning
Step-down buffer
Slack for re-evaluation after a model or provider change
A few days per increment
Learning time
Protected hours in capacity, not stolen from it
4 hours per person per month
Workforce topic
What the delivery lead does
Changing ceremonies
Keeps facilitation human; uses AI for preparation, never to replace the conversation
Reporting pressure
Refuses to report AI speed-up figures that exclude review
Uneven pace across teams
Plans each team at its own stage; never forces one stage across a train
Own role change
Moves time from compiling status to removing blockers and evidence planning
13. Anti-patterns and stop conditions
Anti-pattern
Why it fails
Instead
Speed-up in the plan, review off the plan
Reviewers become the bottleneck; approvals go unread
Book review as work
Agent-closed risks
A summary is not a risk decision
Only the risk owner closes a risk
Status without sources
Leaders act on figures nobody can trace
Every line links a ticket
Evidence at the end
Release dates slip or controls are rushed
Evidence steps in every increment
One stage for the whole train
Teams differ in readiness
Plan per team, per use case
Stop condition
What the delivery lead does
Evidence step missing before release
Moves the date; flags it to the release manager
Review load over budget
Raises it with the engineering manager; the item pauses
Model or provider change
Re-plans the re-evaluation before the release
Dependency owner missing
Escalates to the sponsor; work that depends on it does not start
14. Action kit and 30/60/90
Planning checklist. Use it at every increment or sprint planning.
## AI work in this plan
- [ ] Every delegated item names its reviewer and has review time booked
- [ ] Every delegated item has an evaluation run before review
- [ ] Evidence steps for the change record are dated
- [ ] Dependencies on shared assets have an owner and a release date
- [ ] RAID: AI-specific risks listed (evaluation gaps, provider change, reviewer load)
- [ ] Tech-debt items from reuse warnings and "create" decisions reviewed
- [ ] Step-down buffer exists for this increment
Questions to ask your enablement lead
What review time per artifact are other teams measuring, so my plan uses real numbers?
Which evidence does the change authority expect for Stage 3 and Stage 4 work?
Is there a shared status or RAID prompt in the catalog I can reuse?
Days 1 to 30
Days 31 to 60
Days 61 to 90
Goal
Make hidden work visible
Plan it
Run on evidence
Actions
Stage 1 status drafting; list every AI-delegated item in flight; measure its review time
Add review, evaluation and evidence steps to the plan; reviewed status prompt; RAID categories for AI risks
Agent-drafted RAID summary with owner confirmation; readiness view linked to the change record