Before a bug bash, how do you prepare the build, the data and the area split?

## The preparation is the event A bug bash looks improvised from the outside and is not. Every minute the participants spend on setup, access or confusion is a minute of a scarce, expensive, simultaneous window that will not come back. Preparing well means having four things ready — the build, the data, the areas, the channel — plus one thing that is nearly always forgotten, which is time booked for the aftermath. ## 1. A pinned, smoke-checked build Name one version and one environment. Block deploys for the window and tell the people who might deploy, in writing, that they are blocked. Then use it yourself for twenty minutes beforehand and walk the main flows. The reason for the walk-through is specific. On a warehouse stock ledger, imagine the stock-adjustment save intermittently timing out under load — it succeeds most of the time and hangs for a few seconds otherwise. With twenty-three people saving adjustments at once, that intermittent timeout becomes the loudest signal in the room: a dozen near-identical reports, several participants convinced the whole environment is down, and a general belief that the build is rubbish. One person's warm-up pass catches it, and then you either fix it, restrict the area, or post it as known and tell everyone in the briefing. The rule is simple: **any defect the organiser already knows about must be visible before the doors open**, because a crowd rediscovering it costs more than it is worth. ## 2. Seeded accounts and interesting data Hand out credentials in advance. A single shared account for twenty-three people is a false economy: people collide on the same record, and one person's edit becomes another person's mystery. Seed one account per role — picker, stock controller, auditor, read-only viewer — with the role differences that matter, because permission edges are one of the areas a mixed crowd genuinely probes well. Seed the data into states that took real setup to reach: a location holding 1,438 units, a purchase order received in part, a stock count that ended out of balance, a record in a locale whose decimal separator and date order differ from the default. Empty data means everyone spends the first fifteen minutes creating records, and creating records is one narrow slice of the product. ## 3. The area split Carve the product into named areas — not features in a backlog sense, but places a person can be sent: receiving, put-away, adjustments, stock counts, transfers, reporting, permissions, search, settings. Aim for roughly one area per participant, weighted so recently changed and higher-risk areas get more than one pair of eyes and static areas get none. Assign explicitly rather than letting people choose. Left to themselves, crowds converge on the home screen and the newest feature, and the reconciliation report gets nobody. Give each person a fallback area for when theirs is exhausted after twenty minutes, and be relaxed about people wandering in the last stretch — the split is there to prevent the default failure mode, not to imprison anyone. ## 4. One channel and one format Decide before the start where reports go and what a report minimally contains: a one-line title in an agreed shape, the area tag, the account used, and enough to find it again. Keeping the capture bar low is deliberate — during the window you want observations flowing, and the detailed investigation of any individual finding is work for afterwards, done by someone who can do it properly. Name one person who is not hunting at all and whose whole job is watching the channel for duplicates and asking for the one missing detail while the reporter is still at the keyboard. ## 5. The briefing and the aftermath Spend five minutes at the start on: what the build is, what is in scope, what the known issues are, what the areas are, where reports go, when you stop. Say explicitly what is *not* wanted — for example, cosmetic wording opinions on a screen that is about to be redesigned — otherwise you will get thirty of them. Then book the aftermath. Sorting a pile of a hundred-plus raw reports takes hours, and if nobody owns it, the pile rots and attendance at the next bug bash falls. A common failure is to book ninety minutes of twenty-three people's time for the hunt and zero minutes of anybody's time for what follows. ## Warm-up and logistics Small things that repeatedly matter: check that new participants can actually log in the day before, not at the start; have a helper on standby for access problems so they do not eat the organiser's window; provide a short crib of unfamiliar domain vocabulary for visiting participants; and if people are remote, use a channel that keeps history rather than a call where findings are spoken and lost.