In the basement of the FBI’s Hoover Building, a small team worked for two years in one room with the cubicle panels taken down. One adviser called it a tech startup. The bureau had already spent about $405 million on Sentinel, a case system its agents had been waiting on for years, and in the autumn of 2010 it had taken the work back from its contractor.
The team broke what was left into 670 small pieces, each something an agent should be able to do, and built them in two-week sprints. Every sprint ended on time, finished or not. “We did demos every other Friday with a host of stakeholders,” the bureau’s chief technology officer, Jeff Johnson, said later. The case has the rest, including the date the team missed.
Short rounds, fixed length
Work in short, fixed rounds, and end each one with something that works and can be shown.
The word comes from Scrum, a way of running software teams that Ken Schwaber and Jeff Sutherland first presented in 1995. A scrum is a rugby formation, and the picture is older than software: in 1986 a Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka described companies in Japan and the United States dropping the old, sequential way of developing products for one in which, as in rugby, the ball gets passed within the team.
The current Scrum Guide sets the rules plainly. A sprint is a fixed length of one month or less, and the next one starts as soon as the last one ends. During it, nobody makes changes that would endanger the sprint’s goal, and quality does not drop. Shorter sprints, the guide says, give more chances to learn and limit how much cost and effort is at risk at any one time. Each sprint “may be considered a short project.”
Think of a renovation where the builder hands over one finished room every two weeks, instead of opening up every wall in the house at once. If the kitchen runs late, you know in a fortnight, and you still have a working bathroom.
A number every two weeks
The fixed length is what made Sentinel’s trouble visible. The FBI had planned to finish development by September 2011. In August, the Justice Department’s inspector general found the project 88 percent of the way through its schedule with half the functionality built.
Because every sprint produced a count, the inspector general could also project forward. The team was finishing about 80 “story points,” a rough measure of work, per sprint. At that rate, the auditors estimated in late 2011, Sentinel would be done around June 2012. It reached every FBI employee on 1 July 2012.
A project measured in years can look fine for a long time. A project measured in two-week rounds shows its pace while there is still time to argue about scope, money, or hardware.
Where sprints mislead
The count is only as honest as what a team agrees to call finished. The FBI’s own plan said work counted as complete at the end of a sprint only if it had been fully tested and was ready for every user. The inspector general found the bureau hadn’t documented whether the work it accepted met that standard, and that some had been marked complete before required testing had ended. That made the reported progress hard to check. Agreeing what “finished” means is a separate idea, the definition of done.
The name can mislead too. A sprint sounds like running flat out, but the principles behind the 2001 Agile Manifesto say sponsors, developers and users “should be able to maintain a constant pace indefinitely,” and the Scrum Guide speaks of a “sustainable pace.”
Imagine a five-person marketing team that adopts two-week sprints and fills every one to the brim. Half the work rolls into the next sprint each time, and the end-of-sprint review becomes a list of apologies. The rhythm is there, but nothing is finished at the end of the round, so the round may stop telling anyone anything.
One feature per session
Anthropic ran into something similar when it asked a coding agent to build a web app over many sessions, each starting with no memory of the last. In a 2025 write-up, the company said the agent “tended to try to do too much at once,” attempting to build the whole app in one go. It often ran out of context in the middle of a feature, leaving the next session to guess what had happened and get the app working again.
The fix looked a lot like a sprint. The agent was asked to work on one feature at a time and to leave the code in a clean state at the end of each session, committing its work to git and writing a progress note for the next session. Anthropic said this incremental approach “turned out to be critical” to curbing the agent’s habit of doing too much at once. Its rounds were sessions rather than calendar weeks, and the write-up describes one internal experiment on web apps, but the shape is the same: a small, finished piece at the end of every round.
In the Hoover Building basement, the sprints didn’t make Sentinel ship on time. They made it possible to see, months ahead, roughly when it would.