Quick answer: Most bug bashes happen pre-launch. A weekly 90-minute bug bash mid-sprint catches regressions before they ship; the team stays familiar with bug-finding.
Bug bashes pre-launch find launch bugs. Bug bashes mid-sprint find sprint bugs. Both matter.
Same time each week
Friday 3pm. Predictable; team knows to plan around it. Becomes a rhythm.
Rotate the area focus
Week 1: combat. Week 2: economy. Week 3: UI. Coverage is broad over a quarter.
Time-box at 90 minutes
Engineers and designers tire. Beyond 90 minutes, signal drops. Quit while you're winning.
Track week-over-week
Bug count per bash; sev breakdown. Trends indicate quality drift; bash data is its own dashboard.
“Weekly bashes are quality maintenance. The maintenance is cheaper than the alternative.”
If your team doesn't bash regularly, start with one. The signal-to-effort ratio is high; you'll keep doing them.