Every other Friday in 2010 and 2011, the team rebuilding the FBI’s Sentinel case system ended a two-week sprint by showing what it had finished. The bureau’s own plan set the bar. A piece of work could be called complete only if it had been fully tested during that sprint, was ready to go out to every user, and could be shown at the demo.
The Justice Department’s inspector general looked at those demos and the records behind them. The FBI hadn’t documented whether any of the work it had accepted as complete met those three conditions. Some of it had been called complete before required testing had finished. The project’s product owner, the person tracking what was finished, told the auditors that the criteria only “broadly” informed the team whether work had been completed. From the presentations alone, the inspector general wrote, it “had no basis to determine” whether the work shown was ready for the field.
The case has the rest of Sentinel’s story.
A finish line everyone shares
Agree in writing, up front, what must be true before a piece of work counts as finished.
The term comes from Scrum, the method Sentinel’s team was following. The Scrum Guide calls the Definition of Done “a formal description” of the quality a piece of work must reach. Until an item meets it, the item can’t be released “or even presented” at the end-of-sprint review; it goes back on the list. If the wider organization has a standard, every team must meet it at minimum, and teams working on one product must share the same definition.
The rule is strict for a reason. A progress report is a sum of pieces someone has called finished. Sentinel’s progress was counted in “story points,” a rough unit of work, and the inspector general said that without knowing whether the completion criteria had been applied, it couldn’t verify how many points the team had really finished. If the pieces aren’t really finished, the sum can look healthy while the untested work collects at the end, which is how projects can sit at 90 percent done for a long time.
Think of a house sold as complete. The builder means the walls are up and the roof is on. The buyer means the taps run, the lights work and the inspector has signed off. Both of them say “done,” and they find out they disagree on moving day.
What goes on the list
A useful definition is short and checkable. For Sentinel, it was three tests a stranger could apply: tested, ready for every user, demonstrable. Writing “high quality” would not have helped, because nobody could tell from looking whether a piece of work met it.
It also has to be applied every time, at the moment work is declared finished. Sentinel had the words. What the inspector general found missing was the record that anyone had checked work against them before counting it.
Imagine a small team that adds a step to its definition of done whenever something slips through: a review, then a second review, then a sign-off from someone in another department. Six months later, finishing anything takes a week of waiting. The list may have stopped describing what “finished” means for this product and started recording every past mistake. It is worth asking, from time to time, whether each item still earns its place, and a retrospective is one place to do it.
Agents that stop when it looks done
Claude Code’s documentation puts the problem bluntly: “Claude stops when the work looks done.” Without a check it can run, the documentation says, “looks done” is the only signal available, and the person using it becomes the one who has to notice every mistake. Its advice is to give Claude something that returns a pass or a fail, such as a test suite, a build that has to succeed, or a screenshot to compare against a design.
Anthropic ran into the same gap when it had a coding agent build a web app over many sessions. In a 2025 write-up, the company said the agent tended “to mark a feature as complete without proper testing.” It made changes and even ran some tests, but often didn’t notice that a feature failed end to end. Two changes helped. An early session wrote out more than 200 features, each marked “failing,” and later sessions were told to change only that status. And once the agent was told to test through a browser “as a human user would,” it mostly did well at checking features end to end, though it still missed some bugs it couldn’t see.
Those pre-written feature checks and tests played a similar role: written before the work started, the same for every session, and checked by running the thing.
Sentinel’s team wrote its finish line down. The inspector general’s finding was about the step after that: checking each piece against it before calling it complete.