How My Team 4x'd Our Story-Point Output — by Teaching AI to Do the Repetitive Work

Every DevOps team has a dirty secret: a huge share of the sprint never makes it into the sprint.

It gets eaten. By the QA environment that fell over at 2pm and needs someone to dig through logs. By the fifth database backup-and-restore request that week. By the "can you spin up a server for testing?" pings that arrive faster than you can close them. None of it is on the board, but all of it is on your people — and by Thursday, the planned work is behind, not because the team was slow, but because the team spent half the sprint firefighting.

That was us. We were a DevOps and cloud-infrastructure team supporting a multi-tenant enterprise SaaS platform, and our velocity wasn't being limited by skill or effort. It was being limited by interruption. So instead of asking the team to work harder, I asked a different question: how much of this repetitive work could we teach AI to do — and how much sprint capacity would that give us back?

The answer turned out to be a lot. We measured it, honestly, and the planned-work output roughly quadrupled.

First, we separated the work that was eating us alive

Before automating anything, I made the team categorise where the time was actually going. Two categories dominated — and both were perfect candidates for AI, because they were repetitive, pattern-based, and pulled skilled engineers away from planned work.

Outage and incident debugging. When a QA environment went down or a production service started throwing 5xx errors, the response was always the same shape: someone drops everything, pulls logs from the impacted window, checks heap usage, CPU, error patterns, and tries to find the cause. Hours of skilled attention, completely unplanned, every time.

Database backup and restore. A constant drumbeat of requests — restore a masked production database to a lower environment, take a backup before a risky schema change, sync test data across servers. Individually routine. Collectively, a part-time job nobody had budgeted for.

These two alone were quietly consuming a large slice of every sprint.

Then we taught AI to absorb it

The shift wasn't "automate everything." It was building AI agents and reusable skills that handled the repetitive core, while the team kept judgment and final sign-off. A few that moved the needle most:

An incident-analysis agent. We built a Claude agent that, when a service started misbehaving, would analyse the alarms and logs across the impacted period — heaps, errors, utilisation, recent changes — find the probable root cause, and suggest a fix. For some issues it went further and raised a pull request for the team to review; for others it handed back a root cause and a recommendation to vet. The engineer went from investigating from scratch to reviewing a hypothesis. That's a completely different — and far faster — kind of work.

A monitoring agent for live outages. During one container-stability investigation, instead of a person babysitting the environment, we ran a background agent to watch it continuously and report anything abnormal. It freed a skilled engineer from staring at dashboards while still keeping eyes on the system.

Automated database backup and restore — with masking. We automated the whole repetitive flow: take the backup, apply data masking, restore to the target lower environment. The thing that used to be a manual, interrupt-driven chore became a reliable, hands-off operation — handing back hours of sprint time every week.

Self-service environment management. We made QA and stage servers auto-manage themselves — stopping when idle, and letting users restart them on demand from a simple page — which removed an entire category of "can you bring up a server?" requests from the team's plate (and cut cloud cost as a bonus).

The part that mattered most: reusable skills, not one-off scripts

Here's the distinction that made this compound rather than just help once.

We didn't only automate whole tasks. We built reusable skills — focused capabilities the team could pull into many different tasks, fully or partially. A skill to scan our server and application repositories for breaking changes along an upgrade path before we attempted it. A code-review skill. A skill to keep task updates, checklists, and notes current in our project tool without manual typing.

Because these were reusable, they didn't just close one ticket — they made every related ticket faster. An engineer tackling a new task could reach for an existing skill and finish in a fraction of the time, even if the skill only did part of the job. The library of skills became a force multiplier that grew with every sprint. The more we built, the faster everything moved.

How we proved it was real: story points, with and without AI

I'm wary of automation claims that can't be measured, so we built the measurement right into how we tracked work. For tasks, we recorded the story points with Claude and a parallel estimate of what the same work would have cost without it.

That comparison did two things. It kept us honest — we could see exactly where AI was genuinely saving effort and where it wasn't worth it. And it made the gain undeniable: across the repetitive and skill-supported work, the same team was completing roughly four times the planned story-point output it could before, because the work that used to eat the sprint was now largely absorbed by agents and skills.

The team wasn't working longer hours. They were finally spending their hours on the planned, valuable work — instead of on the interruptions that used to quietly consume it.

The approach, if you want to do the same

You don't need our exact agents. You need the pattern:

Find the repetitive, pattern-based work eating your sprint → build AI agents to absorb the whole tasks, and reusable skills to accelerate the rest → keep human judgment on review and sign-off → and measure the gain honestly, with and without AI, so you know what's actually working.

The breakthrough isn't a single clever automation. It's treating AI as a growing library of team capabilities — agents that handle the interruptions, skills that make everything else faster — and protecting your sprint from the work that was never on the board in the first place.

I've kept this to the approach rather than the build detail. If you'd like to free your own team's sprint capacity this way and want to talk through how, I'm always happy to. [Let's talk →]

How My Team 4x'd Our Story-Point Output — by Teaching AI to Do the Repetitive Work