AI can draft. It cannot decide.

The teams I work with are right to be excited about AI, and the good ones are already wiring it into how they refine, document, and report. The question that decides whether it helps is not how much work AI can take, but which work was never supposed to leave the team in the first place.

Walk onto almost any agile team this year and you’ll find the same conversation already underway: not whether to use AI, but how far to let it in. That energy is healthy. The teams reaching for it are the ones paying attention, and I’d rather coach a team that’s overusing a new tool than one that’s pretending it doesn’t exist. So I want to be clear up front that none of what follows is a brake on the enthusiasm. It’s about where to point it.

Here is the distinction I keep coming back to with teams. AI is very good at producing a draft, and neither good at nor meant for deciding which draft is right. Almost everything that goes well or badly with AI on an agile team traces back to whether the team kept that line clear.

The work around the work is where it earns its place

The first wins are rarely in the code. They’re in the work that surrounds the code, the refinement and the writing-up and the reporting that eats a team’s week. In backlog refinement, AI turns a rough idea into a first-pass story with acceptance criteria and the edge cases someone would otherwise have forgotten, and the team reacts to a draft instead of staring at a blank one. It summarizes a long thread into the decision that actually got made. It assembles a status view out of the data in Jira rather than out of someone’s evening before the review. Atlassian Intelligence does a fair amount of this inside the tools a team already lives in, which lowers the cost of trying it.

I’ll go further than “it helps.” On engineering work itself, with a person reading every change before it lands, AI genuinely moves things along. We built a generative AI workflow for a client that correlates roughly 100,000 incident signals a month into the handful that matter, and incident resolution got about 30% faster, not because the model decided anything, but because it cleared the noise so the on-call engineer could. You can read how that one came together. The shape is always the same: AI does the volume, the person does the judgment.

The work that should never leave the team

Now the harder half, and the reason teams lose the plot. There is a category of work that looks like overhead and is actually the team thinking, and handing it to AI feels like a productivity win right up until the team gets worse.

Prioritization is the obvious one. What a backlog says is settled; why it’s ordered that way is a conversation about value and risk that a team has to have out loud, because the having of it is what aligns them. Estimation is the same trick. The number a team lands on matters far less than the disagreement that surfaces while they get there, the moment someone says “wait, that story hides a migration” and everyone recalibrates. Ask AI for the estimate and you get a number with none of the understanding that made the number worth having.

And the definition of done is a promise about quality, which means it needs an owner who can be held to it. A model can suggest what done might include. It cannot stand behind the promise when a release goes sideways, and a promise no one stands behind is just a wish.

The danger was never that AI is bad at the work. It’s that it’s good enough at the thinking to make you stop noticing you’ve stopped doing it.

None of these tasks is protected because AI would fail at them. AI would produce something plausible for every one. They’re protected because the doing of them is how a team stays good. Outsource the toil and you free people up; outsource the judgment and you have a team that ships faster and understands its own product less every sprint.

Treat it as a practice, not a permission slip

The teams getting durable value don’t decide AI is allowed and move on. They treat it as a practice they tune, which is the most agile thing they could do with it. They agree, as a team, where it’s welcome and where it isn’t. They put light governance around what data it can reach, because an assistant that can read across everything will read across exactly the access nobody got around to scoping. They keep a named person accountable for anything that ships. And they inspect how they’re using it the same way they inspect everything else, in the retro, with the willingness to change their minds.

That last part is what makes this an agile problem rather than a tooling one. The instinct that already serves these teams, keep the thinking close, automate the toil, adapt as you learn, is exactly the instinct that gets AI right. The technology is more capable than anything we’ve pointed those habits at before. The habits don’t change.

So bring AI onto the team, and bring it on with both hands. Let it draft the story, write up the decision, build the report, clear the noise. Just keep prioritization, estimation, and the definition of done where they belong, with the people who have to live with the results. If you want to see where AI belongs on your teams and where it doesn’t, see where delivery is getting stuck.