1.Why Agentic AI Teams: Scrum with Autonomous Coworkers is worth getting right
A large part of the module is spent on writing backlog items an agent can safely execute, which turns out to be the same discipline good refinement always required: if an item is too ambiguous for an agent to execute safely, it was also too ambiguous to estimate for a human, and the fix is to clarify the item, not to engineer a better prompt around its ambiguity. Scenarios include triaging a batch of agent-generated pull requests under time pressure, and a decision lab where an agent shipped a defect overnight with no human awake to catch it, forcing the team to examine where the review gate actually was.
2.How it works in practice
The module closes on running the Scrum events with non-human contributors without letting the Daily Scrum collapse into a review-queue triage meeting, and on the capacity conversation that leadership inevitably raises: throughput went up, so should headcount go down. The module's answer is that the team did not get faster, it moved the constraint, and the honest question is where the team wants that constraint to sit now, not whether the constraint disappeared.
3.Role reality
Every line on the left reads well in a vendor deck. Every line on the right is what running an agentic team actually requires.
| Textbook theory | Delivery reality |
|---|---|
| Agents multiply team output. | Agents multiply the number of pull requests. Output only rises if review capacity rises with it, and it rarely does. |
| The agent is accountable for what it produces. | An agent cannot be accountable. The human who approves the merge owns the change, the incident and the audit trail. |
| More automation means less process. | It means more process, applied earlier. Guardrails, permissions and rollback paths have to exist before the agent runs, not after. |
| Definition of Done stays the same. | It grows. Provenance, permission scope and a named reviewer become mandatory fields, not optional notes. |
| Speed is the headline metric. | Escaped defects and review backlog are the real headline. A fast team that ships bad decisions is not fast, it is early. |
4.Core delivery pillars
Four disciplines that keep an agentic team fast and accountable at the same time.
No pull request merges without a person who can explain the change line by line in review. The agent's confidence is not evidence.
Every agent-touched change records which agent, what data it could access, and what it was permitted to change. Missing provenance blocks the merge.
Treat reviewer capacity as the team's real throughput ceiling. Cap the number of agent-generated items in review at once, the same way you would cap work in progress.
A low-risk internal tool change and a customer-facing payment change do not get the same level of agent autonomy. Tier the oversight to the damage a mistake could do.
5.Signals that expose a badly run agentic team
How long agent-produced items wait for human review. Rising age means the team is faster than its safety net.
Defects reaching production per agent-touched change versus human-only change. The gap tells you where trust is misplaced.
Share of agent output rewritten before merge. High rework means the prompt or the guardrail is wrong, not the reviewer.
How often agents operate above their approved blast radius tier. Any drift is an incident, not a metric.
6.Situations you will be asked to handle
The module puts you inside 4 decisions rather than asking you to recognise the right answer on a list. Each one is a situation practitioners meet, with several defensible options and consequences that follow from the one you pick. The scenarios below are the shape of the judgment the subject demands.
- Lesson 24.3: Game - who should own this work
- Lesson 24.6: Game - triage the agent output
- Lesson 24.7: Decision lab - the agent shipped a defect overnight
- Lesson 24.10: Decision lab - leadership wants to halve the team
7.Common mistakes and why they fail
Concluding a post-incident review with the model made a mistake
Stopping the analysis at a description of what the agent did, instead of identifying the missing policy, review gate, or ambiguous backlog item that actually let the mistake reach production.
Letting the Daily Scrum become a review-queue triage meeting
Spending the fifteen minutes sorting through a backlog of agent-generated pull requests instead of inspecting progress toward the Sprint Goal, which is what the event exists to protect.
Approving agent-authored code and agent-authored tests together, fast
Treating a green pipeline as sufficient evidence of correctness when the same assistant wrote both the implementation and the tests, and a human reviewer spent only seconds confirming it.
Assuming higher throughput means capacity can be cut
Reading an increase in output as headcount that can be reduced, without first establishing that the constraint moved rather than disappeared, and that quality held at the new pace over multiple Sprints.
8.Questions worth asking before you commit time to this
Who is accountable when an autonomous agent introduces a defect?
The Developers, exactly as the Scrum Guide already states. Accountability never transfers to a tool. A review that concludes only that the agent made an error has identified a cause but not the actual finding, which is the missing policy or review step.
How do you write backlog items that an agent can execute safely?
Apply the same refinement discipline good teams already use: if the item is too ambiguous for an agent to execute without risky guesses, it was too ambiguous to estimate reliably for a human either. Fix the item's clarity rather than trying to compensate with a better prompt.
What is wrong with an agent writing both the implementation and its tests?
A green pipeline in that setup proves internal consistency, not correctness, since the same source generated both halves of the check. A human needs to independently verify the tests actually validate the intended behaviour, not just that they pass.
How should a Scrum Master respond when leadership wants to cut the team after seeing agent-driven throughput gains?
Reframe the conversation around the constraint rather than the headcount. Explain that the team did not become faster in an unlimited way, the bottleneck moved, usually to review capacity, and ask leadership where they want that constraint to sit before making a staffing decision.
9.What to remember
- Where human accountability sits when an agent writes and merges code
- A Definition of Done that survives machine-speed throughput
- A situational matrix for defending review against a speed-only metric
10.Where this sits in the Scrumling course
Run Scrum when part of the work is done by autonomous agents: who is accountable, what Done means, and why review becomes the constraint.
About 80 minutes of lessons and decision scenarios.
- Lesson 24.1: What changes when a coworker is not a person
- Lesson 24.2: Accountability does not transfer to an agent
- Lesson 24.4: Writing backlog items an agent can execute
- Lesson 24.5: Definition of Done when an agent wrote it
- Lesson 24.8: Capacity, throughput and the illusion of speed
- Lesson 24.9: Running the events with non-human contributors
- Lesson 24.11: Trust, audit trail and the human in the loop
- Lesson 24.12: Retrospectives for agentic teams
- Lesson 24.3: Game - who should own this work
- Lesson 24.6: Game - triage the agent output
- Lesson 24.7: Decision lab - the agent shipped a defect overnight
- Lesson 24.10: Decision lab - leadership wants to halve the team
Assessment: Agentic AI Teams quiz