TRACK 1 – FOUNDATIONS

Goal: Understand what a user story is and how it represents user intent

1. What is the goal of the user when they select “Internal Transfer” from the menu?

2. What information must be known before a user can select a “From” and “To” account?

3. Why do we write one user story for menu options and another user story for selecting accounts instead of one giant user  story?

4. Why did we create a BRD and also write user story? Is that the norm?

Foundations takeaway:
“I can recognize a clear, user-focused story and explain what the user is trying to do.”

TRACK 2 – INTERVIEW READY

Goal: Learn how to explain user story decisions in an interview

1. How would you explain the business value of the ‘Select Internal Transfer’ menu option to an interviewer?

2. How would you describe your role in identifying dependencies between digital banking and core banking systems?

3. What assumptions would you validate with the product owner before finalizing these user stories?

4. How would you answer: “Tell me about a time you handled system errors in your requirements”?

 Interview takeaway:
“I can confidently talk about why user stories were written the way they were.”

TRACK 3 – EARLY BA

Goal: Write implementation-ready stories that support development & testing

1. What conditions must be met before a user story can be considered ready on the Retail Banking Project

2. What error scenarios should be captured when the core banking system fails to respond?

3. How do you ensure developers understand which system is the source of truth?

4. How do you handle accounts that have changes in the core banking after the recurring payment was setup that makes the transfers now ineligible?

Early BA takeaway:
“I can write stories developers can build and testers can test without constant clarification.”

TRACK 4 – PRACTICING BA

Goal: Improve quality, reduce rework, and influence delivery

1. Where would you draw the line between functional requirements and non-functional requirements in these stories?

2. How do you prevent overloading user stories with technical logic while still capturing system behavior?

3. What risks do you see in internal transfer flows that should trigger upstream conversations?

4. How do you know when error handling deserves its own epic or feature instead of individual stories?

Practicing BA takeaway:
“I can spot risks early, guide others, and protect delivery quality.”