the brief — decisions
Decisions
The brief does not end at understanding. It ends with the decisions the trio has made. Decisions names what the team will pursue to close the gap, what approach will guide the solution, and what was considered and explicitly set aside.
The decisions here are the last upstream decisions before the solution is shaped in Scope. They commit to a principle for this feature — "we will remove the switching, not improve the tools" — rather than a technical specification. They are more specific than Direction (they are about this feature, not the whole product), and less specific than the solution (they do not yet describe what will be built). That is the right level: specific enough to constrain the solution, general enough to let the right solution emerge from Scope.
Rejected options are as important as the chosen direction. When a rejection is verbal, it resurfaces two sprints later as if it had never been considered. When it is written with one sentence of reasoning, it stays decided. The record protects the decision from relitigating itself.
Decisions — Gal's grading brief
Direction: Build automatic MCQ calculation and a per-student marking view inside the platform, keeping Gal in one place for the full grading workflow. A submit-to-school action generates a platform confirmation receipt — closing the uncertainty loop she currently resolves by checking email the next morning.
Rejected: Export to a pre-populated spreadsheet. Improves the arithmetic but preserves the tab-switching. The Experience Snapshot showed that switching — not calculations — is the source of errors at student 24.
Deferred: Submit results to school with receipt. Cannot be designed until we observe the school admin's side. Named as a Risk.
How to apply this
- ✓ Write rejected options before writing the chosen direction. Starting with the chosen direction produces rationalisations. Rejected options are the evidence the decision was made deliberately.
- ✓ Name deferred decisions explicitly — things acknowledged but not yet decided, with the condition that must be met before they can be.
- ✓ Is each decision upstream of the solution? If it describes implementation details — component names, data structures — it belongs in Scope, not here.
- ✗ Do not include technical implementation details. The brief holds the principle. Scope holds the plan.