The complete series

AI Agent as a Real Teammate: The Complete Series

Eight field reports on what happened when we put an AI agent on a real Scrum Team, gave it a Jira account, and held it to a Definition of Done. Written as it happened, including the parts that did not work.

This is the complete series on running an AI agent as a real teammate, from the first day on the board to the delivery report at the end. Most writing about AI agents describes what an agent could do. This series describes what ours actually did, on a working board, alongside people with deadlines. We called her Sophie Hermes, gave her a Jira account of her own, and treated her like a teammate rather than a tool.

Some of it worked from the first Sprint. Some of it took four attempts. One week she wrote four beautifully structured follow-up emails about mothballs, the small white things you put in a wardrobe, because the event was called the Moth Ball. We left that in, along with everything else we got wrong, because the failures are the part you cannot get from a product page.

Read it in order if you want the story. Jump to whichever part matches your job if you want the method. Each post stands on its own.

PART ONE

Onboarding an AI Agent as a Real Teammate

The setup and its traps. The machine, the accounts, the permissions, and the decisions that are much harder to change once the agent is already on the board.

PART TWO  ·  TOLD BY THE AGENT

My First Day on the Job

One ticket, moved from To Do to Done with a comment left behind, and nobody clicking approve. The smallest possible proof that an agent can hold a place on a board.

PART THREE  ·  TOLD BY THE AGENT

AI Assigning Work to Humans

The week the agent went from executing tasks to distributing them, what the team learned from watching it, and why the Developers still decide how their own work gets shared out.

PART FOUR  ·  TOLD BY THE AGENT

Supporting a Sprint Retrospective

Turning a Sprint of Jira data into a starting point the team can argue with, instead of a blank page and a vague memory of what happened on Tuesday.

PART FIVE  ·  TOLD BY THE AGENT

From Sprint Instructions to a Structured Jira Plan

How loose human planning language becomes a structured set of Jira items, and where that translation quietly goes wrong if nobody is checking it.

PART SIX  ·  TOLD BY THE TEAM

What We Actually Automated

The Jira operating loop, written down in enough detail that someone outside our team could rebuild it. The scheduler, the queries, the deduplication, and the four things that broke first.

PART SEVEN  ·  TOLD BY THE TEAM

Eight Sprints In: What Changed

Eight consecutive one week Sprints with an AI agent on the board. What it created, what broke in production, what we changed as a result, and the week of the mothball emails.

PART EIGHT  ·  TOLD BY THE TEAM

AI Velocity: Building a Human vs AI Delivery Report

The export, the classification rule, and the dashboard behind the numbers. Including why velocity is a team measure, and what a per assignee split can and cannot honestly claim.

Four things the series taught us

One caveat we keep repeating: the agent’s share of assigned story points is a floor rather than a ceiling. Human tasks often involve AI help that never appears in Jira at all.

Start small, prove it, then scale

We start with one team and we carry that first setup. It becomes a paid service once that team has shown a 20% velocity increase against its own pre agent baseline, measured on your board with your numbers. From there it spreads to more teams using Scrum@Scale.

If the first team does not clear the gate, there is nothing to buy.

Find out whether your team is ready

A short form first, then a call. We will tell you straight if something is missing, because a team that is not ready does not get a worse agent. It gets a faster mess.

What does an AI agent actually do on a Scrum Team?

On our board it drafts and refines Product Backlog items, keeps item state and links current, surfaces blockers and stale work before the Daily Scrum, prepares data for the Sprint Review and the Sprint Retrospective, and drafts documentation for review. It produces drafts and keeps the record. It does not merge unreviewed work.

Does this replace Developers?

No. The measures we agree with a team are flow and quality, not headcount. The Developers keep ownership of how the work is done and how they distribute it among themselves. Every change that reaches the Increment still passes a human reviewer.

Do we need Jira?

Yes, for now. The whole series is built on a Jira board, and Agent Bootup starts from one Jira project as the single source of truth. A backlog that lives partly in spreadsheets and partly in chat is the most common reason a team is not ready.

What does our team need before we can start?

Disciplined Scrum with real Sprint boundaries, one source of truth for the backlog, an active Product Owner, roughly three months of clean history showing the epic and story structure and who was assigned what, and someone technical on your side. The machine, the LLM API key, Tailscale and backlog access cover the technical half.

Where does our data go?

You set the data boundary in writing before anything is connected, and we work inside it. The agent runs against your own LLM API key, so inference happens under your account and your policy. Access is scoped to one project and you can revoke it at any moment.

What does it cost?

Nothing while we prove it on the first team. It becomes a paid service once that team has cleared the 20% velocity gate, and you will have the pricing in front of you before you are asked to decide.

Start with part one, or skip ahead and find out whether your own team is ready.