Scenario template with exceptions

A blank form, a filled-in example and notes on the fields. The key part of the form is the exception number, which ties a branch to the step where it arises.

A template for describing a scenario so that exceptions are anchored to steps and every branch has its own outcome. Why this way, and where to look for exceptions, is covered in the piece on scenarios and exceptions. Below: the blank form, a filled-in example, and short notes on the fields.

Form

SCENARIO      <name — verb and object: “Returning an item”>
ID            <SC-NN>
Actor         <who starts the scenario>
Goal          <what the actor wants to end up with>
Precondition  <what must be true before it starts>
Trigger       <the event the scenario starts from>

Main flow
1. <step: who does what>
2. ...

Exceptions and alternatives
1a. <condition> → <system behaviour> → <how the branch ends>
...

Rules         <references to business rules: BR-NN — no retelling>
Outcome       <what is true after successful completion>
Undefined     <what is deliberately not described, and the default>
Open          <questions with a date and a default decision>

Example

SCENARIO      Changing the delivery address on a placed order
ID            SC-07
Actor         customer
Goal          receive the order at the new address without cancelling and paying again
Precondition  the order is paid and not yet handed to the courier
Trigger       customer clicks “Change address” on the order

Main flow
1. System shows the current address and a form for the new one
2. Customer enters the new address
3. System checks the address is in the delivery area and recalculates the cost
4. Customer confirms the change
5. System saves the address and notifies the warehouse

Exceptions and alternatives
1a. Order already handed to the courier → no button; a hint to contact
    the courier service, with the tracking number → end
3a. Address outside the delivery area → message, old address kept → end
3b. Delivery costs more → show the extra charge; without payment
    the change is not saved (rule BR-21)
3c. Delivery costs less → the difference goes back to the balance (BR-21)
5a. Warehouse did not confirm within 10 minutes → address saved, notice
    resent every 10 minutes; a task for an operator after three failures
5b. Order handed to the courier between steps 1 and 4 → change
    rejected, customer sees the reason

Rules         BR-21 delivery recalculation when an order changes
Outcome       the order has the new address, warehouse confirmed, cost recalculated
Undefined     changing to a pickup point — unavailable by default
Open          Q-1 can the address change on a gift-wrapped order?
              waiting on the warehouse until 05.11; default — yes

Notes on the fields

Field	Why	Common mistake
Goal	Lets you judge whether the scenario solves the actor’s problem	Repeats the name
Precondition	Becomes part of the “Given” in the acceptance criteria	Missing — and the scenario starts in the wrong place
Exceptions	The number ties the branch to the step where it arises	A general list of “errors” at the end, anchored to nothing
Rules	One rule, one place; every scenario references it	The rule’s text inside the scenario
Undefined	Distinguishes a deliberate gap from a forgotten one	Empty because nobody thought about gaps
Open	Keeps decisions from being made silently in code	A question with no date and no default

How to find exceptions for 3a, 3b…

For every step of the main flow, the six questions from the piece: is the data missing or wrong; did an external system not respond or respond late; did the user stop and come back; was the action done twice; did permissions or status change midway; is someone else doing the same thing at the same time. Branch 5b in the example answers the fifth question — and it is the one usually found only in production.