Why AI projects break traditional Agile — and what to do about it

I’ve watched experienced Agile teams — teams that ship software well — struggle badly the first time their backlog contains a machine learning model. It’s rarely a talent problem. It’s that traditional Agile makes assumptions AI quietly violates.

Three assumptions AI breaks

1. “We know what done looks like.” A user story for a checkout page has acceptance criteria you can verify: the button works or it doesn’t. A model has a performance distribution. Is 87% accuracy done? It depends — on the baseline, the cost of errors, the fairness of that accuracy across user groups. Teams that force model work into binary done/not-done stories either ship too early or iterate forever.

2. “Effort is estimable.” Sprint planning assumes a story can be sized. But you cannot reliably estimate how long it takes to reach a target accuracy, because nobody knows in advance whether the signal is in the data. The honest unit of AI planning isn’t the feature — it’s the experiment: time-boxed, with a question it will answer regardless of outcome.

3. “The product degrades only when we touch it.” Software breaks when someone changes it. Models break when the world changes — data drift, concept drift, new user behavior. A deployed model is not a finished backlog item; it’s a standing commitment to monitor, retrain, and re-validate.

What to adapt

The fix isn’t abandoning Agile — it’s extending it in three specific places.

Plan experiments, not just features. Give research work its own story type with a different definition of done: the question was answered, and the result — positive or negative — was recorded where the organization can find it again. A failed experiment that saves the next team a month is a delivered outcome.

Put data work on the board. Data acquisition, quality assessment, and bias review deserve the same visibility as feature work, because they’re the schedule risk. Most “the model is late” conversations are actually “the data wasn’t what we assumed” conversations that happened too late.

Extend the lifecycle past deployment. Someone owns drift detection. Retraining has a trigger and a budget. Monitoring is a first-class activity in the process — not something the ops team discovers they inherited.

This is the gap the TERRAIN framework was built to close: it keeps the iterative heart of Agile but gives AI’s realities — experimentation, data-centricity, and life after deployment — explicit places in the process. The seven phases walk from team formation through production monitoring, with the feedback loop that turns each deployment into the next cycle’s head start.

If your Agile process has been creaking under an AI workload, start by looking at those three assumptions. The teams that succeed aren’t the ones with the best models — they’re the ones whose process expected the model to behave like a model.

The TERRAIN AI Framework book covers each adaptation in depth — the opening chapters are free to read here, and the full edition arrives on this site in September 2026.