RSMUS.comOne-week sprints
The case for shorter feedback loops
Most software teams run two-week sprints, some run three weeks, and a few venture into four-week cycles. But there’s a compelling case for moving to one-week sprints: they create tighter feedback loops, improve focus, and make team velocity more predictable.
One-week sprints mean planning every Monday, delivering every Friday. This rhythm matches the human work week perfectly and creates a natural recovery period over the weekend.
How one-week sprints work
Monday: planning and kickoff
The team comes together on Monday morning to:
- Review the previous week’s deliverables and blockers
- Inspect what was completed and what needs adjustment
- Plan work for the coming week with clear, achievable goals
- Distribute tasks and identify dependencies early
The key difference from longer sprints is the compressed timeframe forces clarity. Tasks must be specific and achievable in five days, which naturally prevents over-ambitious planning.
Tuesday through Thursday: protected focus time
These days are sacred focus time. The team works without sprint-related interruptions:
- Developers maintain flow without context-switching between planning and execution
- Daily standup meetings take 15 minutes (not 30+)
- Code review happens within the day for immediate feedback
- Blockers surface immediately and get addressed before end of day
Three full days of uninterrupted work is psychologically powerful. Developers can achieve deep focus, make meaningful progress, and feel genuine momentum.
Friday: demo and recovery
Friday morning features a team demo showing what shipped that week. This creates accountability and celebrates progress.
Crucially, Friday afternoon is recovery time. Teams spend 2-3 hours on technical debt, refactoring, learning, or administrative tasks. This prevents accumulated fatigue and maintains sustainable velocity.
Critical point: The Friday recovery period is what makes one-week sprints sustainable. Without it, teams burn out faster than longer sprints because of the planning overhead.
Why one-week sprints work better
Improved predictability
Predicting team capacity for five working days is far more accurate than predicting for ten or more days. External interruptions, sick days, and unexpected complexities have less cumulative impact on a shorter timeframe.
When you consistently deliver every week, project stakeholders develop confidence. Predictability becomes your competitive advantage.
Reduced commitment risk
Planning for five days means committing to less work, which reduces the risk of incomplete sprints. It’s easier to hit your goal when the goal is appropriately sized. Success compounds—teams that ship every week gain momentum.
Faster feedback cycles
Customers and stakeholders see new features and fixes every week instead of every two weeks. Bug reports get addressed in the next sprint (at most five days away) instead of weeks away. This creates the impression of rapid development regardless of absolute speed.
Better focus
Knowing work ends Friday creates psychological urgency that prevents scope creep. Developers naturally prioritize ruthlessly when they know delivery is imminent. This focused work actually produces higher quality code than longer sprints because assumptions are validated faster.
Sustainable pace
By Friday afternoon recovery time, the team isn’t exhausted for the next week. This sustainability matters more than you’d expect. It prevents the burnout cycles that plague teams running longer sprints under constant pressure.
Common objections
“Too much planning overhead”
The objection that planning every week is excessive doesn’t hold up to experience. You’re replacing one two-hour planning session every two weeks with two one-hour sessions every two weeks. The overhead is identical, just distributed differently. And the more frequent checkpoints prevent planning from being wasted on multi-week distractions.
“Tasks won’t be large enough”
This is feature-thinking, not architecture-thinking. If your organization thinks in features larger than one week, that’s valuable feedback that features aren’t decomposed properly. Decomposition happens regardless; one-week sprints just force it earlier when it’s easier to fix.
“Context switching from sprint planning”
Yes, starting the week with planning creates context-switching. But this happens anyway; longer sprints just make it less frequent. The benefit of three days of uninterrupted focus outweighs one day of planning interruption.
“Customers can’t accommodate weekly demos”
Schedule demos on Wednesday or Thursday if Friday doesn’t work. The point is feedback frequency, not the specific day. Even if you only do monthly stakeholder demos, your team can still benefit from weekly internal delivery cycles.
Implementing one-week sprints
Start with a pilot team
Don’t adopt one-week sprints organization-wide immediately. Run one team through it for 2-3 weeks and measure:
- Team velocity consistency
- Sprint completion rates
- Defect trends
- Developer satisfaction
Establish clear rituals
Monday planning should take no more than two hours. Friday demos should take 30 minutes. Daily standups should be 15 minutes. Write these down and protect them.
Protect recovery time
Friday afternoon recovery is non-negotiable. No demos, no external meetings, no production firefighting if possible. This is where technical debt gets addressed and team health gets maintained.
Measure and adjust
Track what works. Some teams discover that one-week sprints work better for some sub-teams than others. Adjust based on your specific context.
When one-week sprints work best
- Early-stage products where customer feedback drives direction
- Teams working on multiple projects where context-switching is constant anyway
- Teams new to scrum who benefit from more frequent checkpoints
- Product teams that need to maintain velocity despite interruptions
When longer sprints might be better
- Research and exploration work where progress isn’t visible weekly
- Long-running infrastructure projects with deliverables spanning many weeks
- Teams with predictable external constraints around specific dates
Conclusion
One-week sprints aren’t a panacea, but they’re a powerful lever for improving team focus and predictability. The psychological effect of shipping something valuable every single week compounds over months.
If your team is struggling with sprint completion, dealing with scope creep, or dealing with context-switching, try one-week sprints for a month. The constraint of the short deadline often reveals that what you thought were blockers were actually planning problems.
The rhythm of planning Monday, building Tuesday-Thursday, and delivering Friday feels natural. It aligns with how humans naturally structure work weeks and creates sustainable velocity that matters.
Learn how RSM’s Enterprise Application & Modernization team helps organizations accelerate software delivery, modernize applications and improve development team productivity.
Enterprise application and modernization services
Kyle Lauffer
Kyle Lauffer is a seasoned software engineer with more than a decade of experience designing and building software solutions across industries. He has supported high-profile organizations, including Rite Aid and the Department of Defense, bringing a practical, detail-oriented approach to complex software engineering challenges. Kyle’s work reflects a strong commitment to quality, craftsmanship and sustainable delivery, as well as a passion for creating positive, productive engineering environments where teams are supported and empowered to do their best work.
