Sprints, demos & reporting
The delivery rhythm: what happens every two weeks and what you receive.
The two-week rhythm #
All build work runs in two-week sprints. Each sprint starts with a short planning session where the milestone plan is broken into concrete tickets, and ends with a demo of working software — deployed to a preview or staging environment you can click through yourself, not a slide deck about software.
What a demo looks like #
- 30–45 minutes, recorded if you cannot attend live.
- Working software first, narrated by the engineers who built it.
- Decisions we need from you, stated explicitly with a recommendation.
- Next sprint plan and any risk that moved.
Written reporting #
After every demo you receive a sprint summary readable in two minutes: shipped, in progress, blocked, decisions pending, budget consumed vs. milestone. Managed-services clients additionally receive a monthly report covering uptime against SLA, incidents, patching status, and cost trends.
NoteIf a sprint summary ever surprises you, our process has failed — surprises are supposed to be impossible. Tell us and we will fix the process, not just the surprise.
A sprint, in calendar form #
| Day | Event | Your involvement |
|---|---|---|
| Mon (wk 1) | Sprint planning — milestone plan → tickets | Optional; plan summary posted same day |
| Daily | Team standup (15 min, internal) | None — blockers reach you only if they need you |
| Thu (wk 1) | Mid-sprint check — scope confirmed or flagged | A two-line update in the channel |
| Wed (wk 2) | Code freeze for demo build, preview env refreshed | None |
| Fri (wk 2) | Sprint demo + decisions + next-sprint preview | 30–45 min, recorded if you miss it |
| Fri (wk 2) | Written sprint summary delivered | 2 minutes of reading |
Maintained by the delivery team · updated quarterly