A scenario has three When steps joined by And — what is wrong, and how do you fix it?

### What the single-When rule is actually protecting The rule is not aesthetic. A scenario is a claim of the form *in this situation, when this happens, this must be true*. One event keeps the claim falsifiable in a useful way: a red scenario names one suspect. Add a second event and the claim becomes *in this situation, after this sequence, this must be true*, which is still testable but no longer diagnostic. In a playlist service, a scenario that signs a listener in, creates a playlist, invites a collaborator and then reorders it will go red for four unrelated reasons, and three of them have nothing to do with the rule the author cared about. There is a second cost, subtler and worse. Multi-event scenarios drift into being narratives of a user journey, and journeys tend to accumulate. Once a scenario is a story, every new requirement looks like another paragraph in the same story rather than a new rule that deserves its own example. Suites that grow this way end up with a handful of very long scenarios that nobody can review and that must run to completion to tell you anything. ### Fix one: demote events to facts Most extra Whens are setup wearing an event's clothes. The question to ask of each is: does the scenario promise anything about this event's outcome? If not, it is context, and context belongs in the Given as a fact. "When Nina creates a playlist and invites Ravi" becomes "Given a shared playlist that Nina owns and Ravi may edit". The scenario keeps the same preconditions, loses two failure causes, and gains a Given that other scenarios can reuse verbatim. This demotion is also what makes a scenario readable. Facts can be scanned; narrated actions have to be simulated in the reader's head to work out what state they leave behind. ### Fix two: split into scenarios When the intermediate events do have promised outcomes, the scenario is covering more than one rule and should become several. Inviting a collaborator promises something — the invitee gains editing rights — and reordering promises something else. Two rules, two scenarios, two Whens, two independent red or green results. Each starts from the state the previous rule leaves behind, stated as a Given rather than inherited by running the other scenario first, so that either can be run alone. A scenario that depends on another scenario having run is a distinct and more serious defect than a multi-event When, because ordering dependence makes results meaningless when the suite is filtered or run in a different order. ### The genuine exception Sometimes the *sequence* is the rule: a promise about repeated or rapid actions, such as two reorders in quick succession settling on the last one, or a duplicate submission that must not take effect twice. Here the repetition is the event under test, not incidental setup, and the right move is to phrase it as one step — "When the editor reorders the playlist twice within a second" — rather than as two Whens. The rule survives, the single-suspect property survives, and the sequence is visible in the text. ### Conjunction steps, the same defect one level down The same reasoning applies inside a single step. "Given the playlist is shared and public and holds 14 tracks" bundles three facts into one sentence. When it fails you learn only that the bundle could not be established. Split it into three lines and a failure names the exact fact. Splitting also makes each fact reusable and makes it obvious when a fact is incidental — three separate lines invite the question "does the rule turn on this one?" in a way a run-on sentence never does. The same goes for a conjunction in the Then: "Then the order is updated and collaborators are notified and the change is logged" hides two failures behind the first one, because a scenario stops at its first failed assertion. Three lines, three independent assertions, and you learn everything the run could have told you. ### What good looks like in review A quick review pass: count the Whens — one; read the Given aloud — every line a fact the rule turns on; read the Then — one promise per line, each observable. When a scenario resists this, it is usually because it is two rules in a trench coat, and splitting it is the answer rather than more careful punctuation.