Scenarios and exceptions: the main flow takes an hour, the alternatives a week
The scenario is signed off, development is under way, and on day three the developer asks: “what if the order was cancelled while the customer was filing the return?” The spec says nothing — and the answer gets invented in the code.
The main flow of a scenario is quick to write down: the customer explains how things should go, the analyst lays it out in steps. Exceptions do not get written that way. Nobody describes them, because nobody thinks about them until they happen. So the first person to see them is the developer — who then decides for everyone.
The break here is not that exceptions were forgotten. They cannot be remembered; they can only be found, by asking every step the same set of questions.
Why diagrams hide them
A process diagram shows the branches somebody drew. An empty spot on it does not look empty: the arrow carries on, and it seems everything is covered. Text works differently. A numbered step asks “and if not?” by itself, and a missing answer is visible at once — there is no line under the step.
This is not an argument against diagrams. A diagram is good at showing order and participants. Exceptions are easier to collect in text and move onto the diagram later if needed.
What a scenario that holds its exceptions looks like
The format does not matter; the anchoring does. Every deviation is attached to the step where it arises, and every branch has its own outcome.
SCENARIO Returning an item
Actor customer
Precondition order delivered, no more than 14 days ago
Trigger customer clicks “Return item”
1. System shows the order lines eligible for return
2. Customer selects lines and a reason
3. System calculates the refund amount
4. Customer confirms the return
5. System creates a request and sends it to the warehouse
1a. No eligible lines → message with the reason, scenario ends
3a. Item bought with a bundle discount → amount per rule BR-12
4a. Customer closed the window before confirming → draft kept for 24 h
5a. Warehouse did not respond → request created as “awaiting warehouse”,
resent every 10 minutes, customer gets the usual confirmation
Outcome request created, customer sees it in their returns listNote 3a: calculating the refund under a bundle discount is not a scenario exception but a business rule. The scenario references the rule rather than restating it — otherwise the second scenario that also calculates a refund will rewrite the rule, and the two wordings will drift apart.
Where to look for exceptions
The questions are the same for any step. Walk them over every line of the main flow and write down everything that has no answer.
| Question for the step | What usually turns up |
|---|---|
| Is the data missing or malformed? | An empty list, a mandatory field that arrived blank from another system |
| Did an external system not respond, or respond late? | No decision on whether to wait, whether to retry, what the user sees |
| Did the user stop and come back? | Unclear whether input is kept and how long a draft lives |
| Was the action performed twice? | A double click creates two requests, a resend makes two charges |
| Did permissions or status change midway? | The order was cancelled while the customer was filing the return |
| Is someone else doing the same thing at the same time? | Two operators take one request, the last one overwrites the first |
The last three rows are edge cases of time: repetition, change midway, simultaneity. Customers almost never name them; support almost always meets them.
Who decides what happens in an exception
Finding an exception is half the work. The other half is getting a decision from whoever owns it. What to do when the warehouse does not respond is decided neither by the analyst nor by the developer, but by the process owner: it is a question of money, deadlines and promises to the customer.
If there is no answer and time is running, it is acceptable to record an assumption: “we assume the request is created without the warehouse’s reply; confirm before release”. A recorded assumption is distinguishable from a decision and can be challenged. A decision made silently in code can no longer be challenged — nobody knows it exists.
Not every exception is an error. The “warehouse did not respond” branch should not show the customer an error message: from their side nothing broke. A scenario exception describes the system’s behaviour, not the text on the screen.
When to stop
Describing everything is impossible and not worth attempting. The criterion is the cost of a failure times its likelihood. Charging money twice is always described, even if it happens once a year. An awkward message under a rare combination of conditions can wait.
What you decide not to describe is better marked than left blank: “behaviour undefined; default — refuse with a generic message”. Then the developer does not invent, and the tester knows what to check.
The sign that someone looked for exceptions: there are more lines under the main flow than in it.
A twenty-minute check
Take a scenario currently in development. For each step ask the first three questions from the table and count the “don’t know” answers. Each one is a decision that will otherwise be made in code.
A ready-made form with a filled-in example — the scenario template with exceptions.
What next
Scenarios operate on objects — order, line, return, request. The next break appears when those objects have no shared description and every participant understands “order” in their own way. That is the subject of the data model.