The Definition of Done When Your System Is Probabilistic: A SAFe SPC's Field Guide

Why the binary Definition of Done breaks

A traditional Definition of Done assumes a binary outcome because the system under test is deterministic. A model breaks that assumption in three ways. Its accuracy varies across data slices, so a single headline number hides the slices where it fails. Its behavior drifts as production data moves away from the evaluation set. And its output depends on a decision threshold that the team, not the model, selects.

Force that into a pass-or-fail checkbox and the team makes a false choice. It either rejects a model that is fit for use because one aggregate number missed, or it accepts a model whose failure cases nobody examined because the aggregate number passed. The 91.3% story is the first error waiting to happen. A story that passes at 93% on average while failing badly on a minority slice is the second. A binary Definition of Done cannot tell those two situations apart, which is the reason it is the wrong instrument for the job.

Write acceptance criteria as thresholds, not checkboxes

An AI-adapted Definition of Done states four things: the metric, the bound, the dataset, and the confidence. A workable form is that the model meets or exceeds a primary metric, stays within a secondary bound, measured on a fixed evaluation set, with a confidence interval that does not cross the threshold. For a claims-triage model that reads as at least a 90% true-positive rate and no more than a 15% false-positive rate, measured on the Golden Dataset, with a 95% confidence interval that stays above the true-positive floor.

The confidence interval is not decoration. A point estimate of 91.3% on a small evaluation set may not be statistically distinguishable from 93%, and a Definition of Done that treats the two as a clean miss is measuring noise. Stating the interval is the honest version of the acceptance criterion, and it changes the sprint-end conversation from an argument about a decimal to a decision about whether the measured range clears the bar.

The Golden Dataset earns a specific role here. It is a fixed, version-controlled evaluation set that every candidate model runs against before a story can close. Golden Dataset regression becomes a sprint gate: a model that drops below the recorded baseline on that set does not pass, in the same way a failing unit test does not pass. The plain reading for a product owner is that the team holds one agreed ruler, and "done" is a measured position against it rather than an opinion voiced at the review.

Test system fitness, not model accuracy alone

Accuracy is the number teams argue about. System fitness is the number that determines whether the feature is usable. A 91% model inside a system that routes low-confidence cases to a human, logs its failures, and holds a fallback can outperform a 96% model that does none of those things and fails silently. The Definition of Done should test the behavior of the system around the model, not the model in isolation.

In practice that means the acceptance criteria cover three behaviors beyond the headline metric: what the system does with a low-confidence output, what it does when the model is unavailable, and whether it captures its failure cases for the next evaluation cycle. A model can hit its accuracy threshold and still fail this part of the Definition of Done, and that is the correct result, because a model that cannot degrade safely is not done regardless of its score.

That third behavior closes a loop the binary Definition of Done never had. The failure cases a model produces in review are not only defects to log. They are the next additions to the Golden Dataset. Each evaluation cycle folds the prior cycle's failures into the fixed set the next model must clear, so the bar the Definition of Done measures against gets harder in exactly the places the system has already shown weakness. A team that captures failures but never feeds them back is measuring against a set that ages out of relevance within a few sprints, and its "done" quietly stops meaning what it did at the start of the program.

Write user stories for machine-learning features

Most ML stories fail at the Definition of Done because they were written as feature stories. A feature story asks whether the thing exists. An ML story has to state the behavior the model must reach and the bound it must not cross. A template that holds up in planning:

As a [role],

I need the model to [behavior]

at [primary metric] of at least [X]

and [secondary metric] no worse than [Y],

measured on [named dataset],

so that [outcome the role can act on].

Filled in for the claims example:

As a claims analyst,

I need the model to flag at least 90% of true positives

with no more than 15% false positives,

measured on the Golden Dataset,

so that I can trust the queue without re-checking every item.

A story written this way carries its own acceptance test. The numbers in the story are the numbers in the Definition of Done, so there is no second argument at sprint's end about what "done" meant. It also gives the team a matching Definition of Ready: an ML story is not ready to start until the named dataset exists, the labels are in place, and a baseline number has been recorded to measure the increment against.

Retrospectives and velocity when the work is experiments

A model sprint often produces an experiment rather than a shipped feature, and the ceremonies must account for that. A retrospective on experiment-driven work asks what the team learned, not only what it shipped. A three-sprint experiment that disproves a hypothesis has returned value, because it closed a path the program would otherwise have kept funding. Record that outcome as a result, not a failure.

Velocity needs the same adjustment. On one system, a model feature was estimated at 8 story points and burned 34 before the team accepted it would not reach production on the planned approach. Counting only shipped points would have marked three sprints as waste. Counting experiments and validated learnings shows where the effort went and gives the next PI a defensible estimate. An unvalidated assumption carried forward without testing is Experiment Debt: like technical debt, it comes due later, usually in the sprint before a release, and at a worse exchange rate than if the team had tested it when it was cheap.

Model Readiness belongs in the PI objectives

At the program level the same distinction must appear in the objectives. A traditional PI objective tracks Feature Readiness: whether the feature is built and accepted. An AI-native Agile Release Train needs Model Readiness as a parallel track: whether the model is measured, inside its envelope on the Golden Dataset, and safe to degrade. The two tracks do not move at the same rate. A feature can be code-complete while the model it depends on is still three points of accuracy short of its threshold. Planning a PI with a single readiness track hides that gap until the release. Planning it with both makes the model's status a first-class objective the business can see, commit to, and adjust, rather than a surprise that surfaces in the last sprint. The AI-adapted Definition of Done is what makes Model Readiness measurable, because it states the exact condition the model must meet before the objective can be called met.

Running a sprint review on a confusion matrix

When the demo is a metric rather than a screen, the sprint review changes shape. The team shows the primary metric against its threshold, the confidence interval, the change on the Golden Dataset since the last review, and the failure cases the model still produces. Stakeholders accept or reject the model against that stated envelope rather than against a feature walkthrough. A review run this way documents the model's position on the distribution and keeps its failures in view instead of out of frame, which is the record a product owner needs to sign off responsibly.

The objection worth answering

The common pushback is that thresholds and confidence intervals just move the goalposts, letting a team accept a model that missed its target. It is the opposite. The threshold, the secondary bound, the dataset, and the confidence level are all set before the sprint starts, and they are measured on a fixed set the team cannot quietly re-pick. That is stricter than a single headline number, not looser, because it removes the sprint-end negotiation where a round figure gets talked up or down. A binary Definition of Done is the one that moves, because it forces a yes or no that the evidence does not support and leaves the real decision to whoever argues hardest at the review.

—-

An earlier post in this series argued that SAFe PI Planning breaks when a sprint backlog includes a model, because the planning assumes deterministic estimates. This is the same problem at the other end of the sprint. If planning has to price uncertainty, the Definition of Done has to measure it. Later in the series I will connect this to continuous authorization, where an AI-adapted Definition of Done becomes the evidence a continuous ATO runs on, and to the production-economics piece, where these thresholds meet real cost at scale.

A probabilistic system can still have a rigorous Definition of Done. It has to be written in thresholds and measured on a fixed set, so the team decides what "done" means before the sprint rather than during the argument at the end.

 —-

Shailesh Patel is CTO of Keystone International Ventures and a SAFe Program Consultant (SPC). He writes about the intersection of AI architecture, federal technology, and the delivery frameworks that connect them.