Writing the User Story for the “Make a Transfer” Screen
In this session we worked in Jira and create the story for the Make a Transfer screen.
View the list of UI/UX terms for form fields
Member Track Questions
TRACK 1 – FOUNDATIONS
Goal: Understand what a “good user story” actually is
Clearly explain what this story does and what it intentionally does NOT do?
Do you know the proper names of each form element on the Make a Transfer screen?
Can you explain why we focused only on what the user sees and can enter on the screen— and not what happens after submission?
Can I tell the difference between information that belongs in the user story versus details that should come from UX designs or later stories?
Foundations takeaway:
“I am able to identify and document only the high-level UI requirements for a screen without including validations or backend logic.”
TRACK 2 – INTERVIEW READY
Goal: Be able to explain your thinking out loud in an interview
If asked “Why did you start here?”, can I clearly justify starting with UI scaffolding before validations and unhappy paths?
Can I explain how this story helps the team de-risk development early by aligning on the screen structure first?
Could I confidently walk an interviewer through how this story would break down into future stories?
Interview takeaway:
“Be able to explain and defend why a user story on a development project should start with UI scaffolding before breaking into detailed validation and unhappy-path stories.”
TRACK 3 – EARLY BA
Goal: Learn to scope stories for delivery, not just documentation
What was the benefit of limiting the scope of the user story to just rendering the form fields—even when I know validations are coming later?
Can I identify which decisions are mine as the BA versus what I should leave to UX or engineering?
How do I know when to write acceptance criteria that support building the screen layout, not enforcing business rules?
Can I articulate how this story fits into a larger epic or feature without trying to solve everything now?
Early BA takeaway:
“Effective delivery means deliberately limiting scope to just building the form view while leaving UX details and business rules for future stories.”
TRACK 4 – PRACTICING BA
Goal: Demonstrate senior thinking and team enablement
Does this story create clear alignment across UX, engineering, and product on what “done” means for this increment?
Have I structured the work to reduce rework when validations and unhappy paths are added later?
Could a developer build this screen without needing to guess or over-engineer beyond the story’s intent?
Am I using this story as a pattern that can be reused for other forms or transfer types across the platform?
Practicing BA takeaway:
“Senior BA thinking is demonstrated by structuring stories incrementally so teams align early, reduce rework, and scale the pattern across features.”