In the programs I've run, the most reliable predictor of a missed production date in a compliance-constrained environment is a security review that wasn't planned into the sprint.
Not because the reviewer caused the delay. Because the program treated security review as something that happens after the sprint closes — and it doesn't. It happens inside the sprint, or it happens to the sprint.
The structural problem
In a standard agile model, the sprint delivers a working increment. Security review, if it's considered in sprint planning at all, is treated as a gate the increment passes through on the way to production. The sprint ends, the artifact is handed off, and the team starts the next sprint while the current increment is in review.
This model fails for a specific reason: security review of a change to a certified system is not a passive validation. It's an active assessment that may produce findings, require rework, or surface dependencies that weren't visible during development. When it produces findings, the sprint that was "done" is not done. The rework goes somewhere — either into an unplanned sprint, or it stretches the current sprint's definition of done backward in time.
In either case, the production date slips. And because the team already started the next sprint, the rework competes with new work for engineering capacity.
The planning failure that creates this is treating security review as a fixed-duration passive gate rather than a variable-duration active assessment with feedback loops.
What security review actually requires
A change to a certified system generates several parallel review activities, each with its own timeline and each able to produce findings that feed back into development.
The security impact assessment determines whether the change affects the system's security posture — whether it introduces new data flows, affects boundary controls, changes authentication behavior, or touches components under specific control requirements. This has to happen before development is complete, not after, because its findings affect what gets built.
The documentation update determines what compliance artifacts have to be revised to reflect the change. For a change that affects the system boundary, the security documentation may need updating before the authorization can be amended. That update is development work, not administrative work, and it takes time that has to be in the plan.
The review itself — the actual assessment of whether the change is consistent with the authorization — happens after the impact assessment and documentation update are complete. Its duration depends on the complexity of the change and the reviewer's current workload, both of which can be estimated in advance.
The integration that works
Security review integrates into delivery cadence when it starts when the sprint starts — not when the sprint ends.
The security impact assessment runs in the first days of the sprint, against the design of the change, not the completed implementation. Findings feed into the sprint's technical work before that work is done. Changes that would have been caught at the end are caught at the beginning.
Documentation updates get sprint capacity like any other task. The engineer implementing the change and the person updating the compliance documentation work in parallel, not in sequence.
The review is scheduled at sprint kickoff, not at sprint close. The reviewer knows what's coming, when to expect the artifact, and what the review scope includes. In my experience, reviews scheduled in advance and handed off with complete documentation take less time than reviews that arrive unscheduled with incomplete artifacts.
The bottom line
The programs I've seen close sprints on time in compliance-constrained environments made one structural decision: they stopped treating security review as something that happens to the sprint and started treating it as something that happens inside it.
Cybaris Consulting advises programs on delivery architecture and security-integrated sprint planning. Start a conversation at cybarisconsulting.com.