The constraint that drives everything
Weekly sprints force a kind of discipline that longer cycles do not. When you have five days to go from a defined requirement to merged, deployed, working code, there is no room for scope creep, over-engineering, or deferring decisions.
This constraint sounds limiting. In practice it is liberating. Teams that work in weekly cycles ship more features, catch problems earlier, and maintain tighter alignment with clients than teams working in two-week or monthly cycles.
Monday: alignment and scoping
Every sprint starts with a Monday call — 30 minutes, not 90. We review what shipped last week, confirm what is being built this week, and surface any blockers. Requirements are already written before this call; the meeting exists to validate them, not create them.
Scope discipline is enforced here. If a feature cannot be defined clearly enough to build and test in five days, it does not go into the sprint. It goes back to refinement.
Tuesday through Thursday: build
Three days of focused building. We use feature flags to decouple deployment from release, which means code can be merged to main at any point without affecting production users. This keeps the main branch clean and eliminates the "big bang" merge problem.
Code reviews happen same-day. We do not queue PRs for a weekly batch review — delayed feedback is expensive and kills momentum. A PR opened in the morning should be reviewed and either merged or returned before end of day.
Friday: test, deploy, retrospect
Friday is for verification, deployment, and a brief retrospective. The retrospective is 15 minutes — what slowed us down, what did we get right, one thing to try differently next week. We write it down. We refer back to it.
Features ship to production on Friday with the client on a call. This creates accountability in both directions: we are committed to having something working, and the client is committed to reviewing it and giving feedback before the next sprint starts.