Intelagile
Scrum in Federal Delivery Has Three Extra Ceremonies
Sprints rarely fail in federal programs because of retrospectives. They fail because the contract, the funding line, and the ATO sit outside the sprint.
Scrum does not fail in federal programs because the team forgot the retrospective. It fails because the thing that decides whether the work ships is not in the room.
A two-week sprint runs inside a twelve-month option period, a funding line that was obligated last fiscal year, and an authorization boundary that was approved before the first line of code. The ceremonies are fine. The boundary around them is wrong.
The boundary is the problem
The Scrum guide assumes a product owner with the authority to order a backlog and a team with the authority to decide how to build. In federal delivery, both authorities are constrained by documents the team did not write.
The contract defines what can be delivered and when it can be paid for. A task order or a CLIN has a period of performance, a set of deliverables, and a ceiling. Work that is not in the contract is not work the team can accept, no matter how valuable it is.
The funding defines what can be started. Obligation happens on a fiscal calendar, and a change in scope often means a modification, which means a contracting officer, which means weeks.
The authorization defines what can be operated. A system that handles controlled unclassified information needs an authority to operate, and the ATO is granted against a described boundary. A sprint that adds a data source has changed the boundary.
DoD's Adaptive Acquisition Framework (opens in a new tab) gives software programs a middle-tier pathway built to move faster than the traditional model. The pathway changes the timeline. It does not change the contract, the funding line, or the authorization.
A team can run perfect Scrum inside those constraints and still deliver nothing that a user can touch. That is the failure mode worth designing against.
Map the artifacts to the contract
The fix is not to abandon Scrum. It is to make the contract artifacts visible in the Scrum artifacts, so the team sees the constraint before it becomes a surprise.
| Scrum artifact | Federal counterpart | What goes wrong |
|---|---|---|
| Product backlog | PWS or SOW, CLIN structure | The backlog grows work the contract cannot pay for |
| Sprint backlog | Task order line items | Sprint scope drifts from the funded scope |
| Definition of done | Acceptance criteria plus ATO evidence | "Done" means demoed, not deployable |
| Sprint review | In-progress review with the COR | The reviewer sees a demo, not a decision |
| Retrospective | Option period decision | Process lessons never reach the contract |
Two of those rows deserve emphasis.
Definition of done. In a commercial sprint, done usually means shippable. In federal delivery, shippable means inside the authorization boundary, with the evidence the authorizing official will ask for. If the definition of done does not include that evidence, the team is accumulating undeployable work.
Sprint review. A review that shows a demo to a stakeholder is theater. A review that puts a decision in front of the contracting officer's representative, with the evidence for it, is a control. The difference is whether the review can change the contract.
The three ceremonies nobody schedules
Federal Scrum needs three events that are not in the guide. They are not replacements for the standard five. They sit alongside them, and they are where the schedule actually gets decided.
The contract modification review. Once per increment, the product owner and the contracting officer look at the backlog and ask which items are inside the current scope. Anything outside is either deferred or turned into a modification request with a cost and a date. Doing this monthly is cheaper than discovering it at delivery.
The authorization boundary review. Once per increment, the team and the security lead compare the system's actual data flows to the boundary in the authorization package. A new integration, a new data source, or a new user population is a boundary change. Finding that in a sprint is a design decision. Finding it in an assessment is a finding.
The funding realignment. Once per quarter, the program manager and the resource manager compare the planned work to the obligated funds. Agile delivery front-loads discovery, and discovery sometimes changes the plan. A quarterly conversation about money is less painful than a year-end reprogramming action.
None of these are agile ceremonies in the textbook sense. All three are how agile delivery survives contact with a federal program.
The first sprint
A team starting Scrum on a federal program should spend the first sprint on four documents, not on velocity.
- The scope map. Every backlog item mapped to a contract line or marked as out of scope. If more than a small fraction is unmarked, the backlog is a wish list.
- The definition of done. Written with the security lead, not for them. It should name the evidence an assessor will ask for.
- The boundary diagram. What data enters, what leaves, where it is stored, who can read it. This is the artifact the authorization is built on.
- The decision log. Who can approve a scope change, who can approve a boundary change, and who can approve a spend. Three names, three paths.
Velocity comes later. It is a measure of a team that already knows what it is allowed to build.
Scrum is not the hard part
The roles, events, and artifacts are learnable in a week. The hard part in federal delivery is that the system the team is building is governed by documents that were written before the team existed and will be amended after the sprint ends.
A team that maps those documents into its ceremonies can move fast inside them. A team that ignores them will keep finishing sprints and missing deliveries, and will keep blaming the framework.