Working Software Every Two Weeks, Demonstrated
Build runs in two-week sprints where the demo is the status report. You see working software early, and scope changes happen at boundaries, never silently.
What Happens in Build
The phase in one sentence, then the mechanics.
Build is deliberately unglamorous: two-week cycles, each ending with a demo of working software, not a slide about promised software. Integration points are tested continuously against the architecture Plan approved, and compliance behaviors, access rules, logging, encryption, are verified as features are built, not audited after. Scope changes are welcome at sprint boundaries, where they are named, priced, and inserted into the plan transparently. Mid-sprint surprises are not, because mid-sprint scope drift is how budgets die. By the final sprints, your staff have already seen the system several times, which is why training in the next phase starts from familiarity instead of fear.
Demos every two weeks. <div> Working software is demonstrated each cycle, so progress is visible and direction is corrected cheaply.
Integrations tested continuously. <div> Connection points run against the architecture every sprint, so surprises surface while they are small.
Compliance verified as built. <div> Access, logging, and encryption behaviors are checked per feature, not retrofitted before launch.
Scope flex at boundaries only. <div> Changes are named, priced, and scheduled at sprint edges, never drifted mid-cycle.
Staff see it early. <div> Your team watches demos from sprint one, so the launch phase starts from familiarity.
What This Phase Produces
Concrete outputs you will see, not abstract promises.
Sprint Delivery
Two-week cycles producing working, demonstrable increments against the signed roadmap.
Continuous Integration Testing
Every integration point exercised per sprint, with failures fixed inside the cycle they appear.
Compliance-as-Built Verification
Security behaviors verified alongside features, documented as they are implemented.
Transparent Sprint Reviews
Demos against acceptance criteria, with your feedback captured and scheduled on the spot.
Change Control
Scope adjustments priced and scheduled at boundaries, keeping the budget conversation honest.
Early Staff Involvement
Operational staff attend reviews, catching workflow friction while it is still cheap to fix.
The Phase Step by Step
How the weeks actually spend themselves inside this phase.
Sprint one and two
Foundation features built and demoed, integration points first-tested, feedback scheduled.
Mid-build checkpoints
Compliance behaviors and integrations verified per sprint; roadmap adjusted transparently.
Feature completion
Remaining scope delivered, edge cases from demos resolved, acceptance criteria met.
Build gate
Launch checklist drafted and verified as buildable, and the phase closes into Launch.
Frequently Asked Questions
Straight answers for practice owners evaluating software build sprints.
What if a demo shows we want something different?
That is the point of demos. Feedback lands in the backlog, gets priced at the boundary, and enters a future sprint if approved. Course corrections cost days here, not months later.
How visible is progress between demos?
The roadmap and sprint board are visible to your owner continuously, and a weekly touchpoint covers anything urgent without waiting for the demo.
Who writes the acceptance criteria?
Jointly, during Plan, per deliverable. Your team defines what done looks like in operational terms, and demos measure against exactly that.
What happens if an integration vendor blocks a sprint?
The sprint reshapes around work that is unblocked, the vendor issue escalates through the channels agreed in Plan, and the roadmap reflects reality instead of wishful dates.