9-Day Build Sprint
A focused build sprint that ships one defined control with test evidence, operator training, usage guidance, and a handoff pack in nine business days.
A strict, fixed-scope delivery sprint for teams that know one control is needed now. The sprint ships exactly one scoped control and leaves an evidence trail operators can follow.
Why a 9-day sprint exists
The sprint exists for a specific kind of stuck. A control you already agreed on is sitting in the backlog while risk accumulates around it. Everyone knows it needs to ship. It keeps slipping anyway, because the team is balancing it against a roadmap, a launch, an incident, or a board ask that feels louder this week.
A nine-day, fixed-scope sprint is a different kind of commitment. It is not a program. It is not a pilot. It is a narrow implementation path you can fund and finish inside one operating cadence — and walk away from with one control that is built, evidenced, owned, and ready for the next gate.
We turn that pressure into one shipped control. Built, evidenced, owned, and ready for the next gate.Three patterns the sprint solves cleanly
The sprint starts when a specific decision needs evidence. There are three patterns that come up most often. They are not abstract — each one has a file or a meeting attached to it.
-
Pattern 01 · Backlog
You know the control, it just hasn't shipped
The fix is identified and agreed, but it keeps getting pushed by louder priorities. The sprint exists to break that loop with a nine-day commitment that is too short to be displaced again.
-
Pattern 02 · Evidence gap
The control runs, evidence doesn't
It works in production, but nothing is captured that an auditor, board, or insurer can read. The sprint adds the evidence layer the original implementation skipped.
-
Pattern 03 · Paper gate
A launch gate exists on paper only
The gate is documented but not wired into the workflow people actually use. The sprint connects the documented gate to the daily path so the policy and the practice match.
How the nine days run
Nine days from scope lock to a control your team can run. The plan is identical every sprint, which is what makes it predictable. The thing that varies is which control you choose.
-
Days 1-2
Lock and design
Lock scope, baseline evidence, design the control, and define acceptance criteria. Day one names the operator who will run it after we leave. The acceptance criteria is the contract.
-
Days 3-7
Build, test, capture
Build or configure the control, test it, capture evidence, and remediate defects. Evidence isn't an afterthought; it is captured as the control runs.
-
Days 8-9
Demo and hand off
Demo the control, train operators, assign ownership, and deliver the usage guide and evidence pack. The named operator from Day 1 walks out of Day 9 with the keys.
Seven artifacts on day nine
Concrete artifacts, not vague advisory hours. By Day 9 you have a working control plus the supporting record that lets your team run it and your reviewers read it.
One implemented control
The control itself, in the system that runs it — built or configured, tested, and live.
Recorded demo
A walkthrough so the next person who joins the team can learn it without scheduling a meeting.
Operator training
The named owner is trained, not handed a doc. The handoff happens in person.
Test evidence
The test results that prove the control behaves to its acceptance criteria.
Usage guide
The day-to-day instructions for the operator running the control.
Evidence pack
The readable artifact for an auditor, board, or insurer. Dated, sourced, and signed.
Next gate memo
The short note that sets up whatever the next decision is, so the sprint doesn't end as a dead end.
One control. Built, evidenced, owned, and ready for the next gate.Operating principle
Three principles every sprint runs on
One control, fully shipped
Nine days for one specific control, with evidence and an owner. Not a program, not a pilot. The sprint refuses scope creep on purpose — that refusal is what makes the date hold.
Evidence captured by default
The control isn't "done" until what it produces is readable to your auditor or board. Evidence is part of the build, not a follow-up phase that never gets funded.
Owners named on day one
Day 1 names who runs it after we leave. Day 9 hands them the keys. The handoff is real because the operator has been part of the work the whole time.
What stays with you, and what this isn't
You stay in control of every decision and every rollout. The line between what we deliver and what we don't is short and explicit, so there are no surprises during procurement or delivery.
- What we deliver
- One implemented or configured control, demo, operator training, test evidence, usage guide, evidence pack, next gate memo.
- One scoped control
- One control, not a program of controls. The sprint refuses to grow because that is what keeps it nine days.
- Not a fix for every governance risk
- The sprint solves one, cleanly. Wider risk pictures belong to the Diagnostic + Playbook engagement.
- You provide the inputs
- Access, SMEs, environment readiness, and approvals. The sprint cannot start on Day 1 without them.
- No outcome guarantees
- No guarantee of regulatory, audit, security, model, or operational outcomes. We guarantee a shipped control with evidence.
Where this leads next
The sprint often surfaces a wider operating need. When it does, the follow-on path stays scoped and evidence-driven, not open-ended.
- Governance & Risk Cadence — set up the recurring forum that keeps the new control fresh and accountable.
- Executive Diagnostic + Playbook — step back and map the wider risk picture if more than one control needs attention.
- Regulatory / Insurer Evidence Pack — wrap the new control's evidence into a packet ready for an external reviewer.
Companion deck: the slide brief carries the same content in a presenter format. Use the slides for the room; use this brief for the operator and the procurement file.