Work sample / Delivery definition
Mock transfer user story
A fictional story that demonstrates how I separate the user need, context, scenario reasoning, and testable behavior.
Portfolio-safe reconstruction based on my story-writing framework. Every account, state, policy, and behavior below is illustrative; it does not describe a Truist system.
Illustrative artifact
Transfers | Scheduled instruction | Review before submission | Happy Path
User story
As a treasury user,
I want to review a scheduled transfer’s key details before submitting it,
So that I can correct mistakes before it enters an approval workflow.
Context
A review step should make the instruction, selected source and destination, schedule, and any unresolved issues clear enough for the user to make an informed submission decision. The example deliberately leaves policy-specific limits and timing undefined.
Acceptance Criteria
Scenario 1 — Review a complete instruction
Justification: A deliberate review helps the user catch errors before submission.
- Given the user has a draft scheduled transfer
- And all required details have been entered
- When the user chooses to review the transfer
- Then the system presents the source, destination, amount, schedule, and approval implication together
- And the system gives the user a way to return to the draft before submission
Scenario 2 — Resolve an incomplete instruction
Justification: A user should understand what must be corrected without losing entered work.
- Given the user has a draft scheduled transfer
- And a required field is missing
- When the user chooses to review the transfer
- Then the system identifies the missing information and does not present the instruction as ready for submission
- And the user can return to the relevant field with existing entries preserved
Scenario 3 — Recheck after a material edit
Justification: The reviewed details should match what the user ultimately submits.
- Given the user has reviewed a complete draft
- And the user changes the amount or destination
- When the user returns to the review step
- Then the system presents the updated details and refreshes any applicable feedback before submission
- And the earlier review is not treated as approval of the changed instruction
Open decisions
What counts as a material change? Which policies control eligibility, timing, and approval? These require validated source rules before an implementation story is ready.
Story boundary
This story covers review and correction before submission. Authorization, execution, notifications, and audit persistence would be defined in separate stories with their own scenarios.