We worked for years with 2-week sprints because that's what Scrum said. 14 months ago we switched to 1 week on one of our projects as an experiment. The results were good enough that we never went back. Today every Sirius project runs on weekly sprints. This is the note with the numbers.
💰 How much does a project on weekly sprints cost? See the complete Costa Rica pricing guide — we bill per deliverable, not per hour, so you know the total before signing.
The problem with 2 weeks
The 2-week sprint has a problem nobody publicly acknowledges: there are 10 days where the team can be going in the wrong direction before the client sees anything. In practice that translates to three symptoms:
- Unscheduled ad-hoc meetings. On day 5 or 6 someone says "this isn't going where we thought" and an improvised sync gets set up. The 1-hour sprint planning becomes 3 hours spread across the sprint.
- Theoretical demos instead of functional ones. When the sprint arrives and the piece isn't done, the demo gets replaced with slides "explaining what we're building". Slides are not product.
- The client loses traction. Two weeks is long enough for the client to cool down on the project: forgets details, prioritises other things, and when the demo comes around doesn't remember what they were going to decide.
We measured this on our own projects. Between sprint 1 and sprint 4 on a 2-week cycle, time lost to rework was 18% of sprint effort. Almost a fifth of the time recycled.
What changes at 1 week
1. The Friday demo is law
When there are 5 days instead of 10, there's no margin for "almost done". Either you ship something demonstrable or you don't ship. That sounds harsh but it's liberating — the team stops promising big features in 5 days and starts splitting them into pieces that actually fit. The split is where the product improves.
In our last 12 projects on weekly cycle, the percentage of sprints where a functional demo did happen rose from 67% (on the 2-week cycle) to 91%. Four times more real demos.
2. Client decisions arrive faster
The client decides things every Friday at demo and every Monday at planning. That's 2 decisions per week vs 1 every two weeks (planning) or 1 per sprint (demo). Twice the chances to correct course, less drama per decision.
3. Ad-hoc meetings disappear
Because the cycle is short, the person who was going to set up an improvised sync on day 7 says "the demo is almost here, we'll cover it then". The number of spontaneous meetings on our last 6 projects dropped from 2.1/week (on the 2-week cycle) to 0.3/week. 86% fewer.
The hard number: 12 projects compared
We took 6 projects before the change (2-week cycle) and 6 after (1-week cycle), all with similar team and comparable scope:
| Metric | 2-week | 1-week | Change |
|---|---|---|---|
| % sprints with functional demo | 67% | 91% | +24 pp |
| Hours/week in meetings | 5.8 | 2.4 | −59% |
| Rework (% effort) | 18% | 13% | −28% |
| Ad-hoc meetings per week | 2.1 | 0.3 | −86% |
| Client NPS at close | 53 | 73 | +37% |
| Total project days (median project) | 84 | 71 | −15% |
The most interesting line: projects close 15% faster on weekly sprints, not slower. The common intuition is "more demos = more time lost in demos", but it's the reverse — less rework more than pays for the overhead.
How we run it at Sirius
Our weekly structure:
- Monday 9–9:30 am: planning. Review what closed last week, what's left, what enters this week. Max 5 big tasks per 2-person team.
- Monday–Thursday: work. Async daily stand-up in Linear/Slack (no live daily — text gets logged and read quickly).
- Friday 2–2:30 pm: client demo. Each finished piece is shown working (not slides). Client tries it live where applicable.
- Friday 2:30–3 pm: short retro. What worked, what didn't, what we change next.
Total: 1.5 hours of meetings per week, including the client. The rest is the team building.
When it doesn't work
There are 2 cases where the weekly cycle doesn't apply:
- Pure research. When we're in discovery (week 1–2 of a new project) we're not demoing "functional feature" — we're demoing "understanding". There the cycle becomes daily (a lot of context to confirm).
- Client who can't do 30 min/week. If the client doesn't have 30 minutes' availability on Fridays, there's no decision, no demo, no sprint. Better to talk about it before signing.
In summary
1-week sprints are not more meetings — they're fewer. They produce real demos instead of slides. They keep the client warm instead of cold. And they drop rework by nearly a third. If your agency or team works on 2-week sprints and it's not for a strong structural reason, trying 1 week for a month is going to surprise you.
