Track 1 – Foundations

Goal: Understand structure, purpose, and basic requirement clarity.

1. Who is the user in this internal transfer story, and what is their primary goal?

2. Why did we separate account eligibility checks instead of just saying “show accounts”?

3. What makes “Account must be active and must be either a Savings account , Checking account , or HELOC” a requirement instead of an assumption?

4. Why is matching currency between From and To accounts important to the user experience?

5. When should we write exact screen text in the user story versus using a dynamic field?

 Foundations takeaway:
You understand what belongs inside a user story and why.

Track 2 – Interview Ready

Goal: Be able to explain decisions and demonstrate BA thinking.

1. If an interviewer asked why you created an epic for internal transfers instead of one large story, how would you explain it?

2. How would you describe your role in identifying the account eligibility rules?

3. How would you explain the dependency on the backend API call in simple business language?

4. If asked “How do you handle system integrations in your requirements?” — how would this example help you answer?

5. How would you explain the difference between static UI text and variable data fields during an interview?

Interview takeaway:
You can confidently talk through their reasoning, not just the format

Track 3 – Early BA

Goal: Write implementation-ready, testable stories.

1. What acceptance criteria would you write to validate that only active Savings, Checking, or HELOC accounts appear in the dropdown?

2. What should happen if the API call fails to return accounts? What error handling should be documented?

3. How would you ensure developers understand that currency in the from and to account  dropdown validation that must occur before submission?

4. How do you prevent ambiguity when documenting eligibility rules?

5. How would QA test the currency matching requirement?

Early BA takeaway:
You think in terms of validation, clarity, and system behavior.

Track 4 – Practicing BA

Goal: Elevate thinking, manage risk, and improve requirement quality.

1. Where would you document the eligibility rules long-term — within each story or as a reusable business rule? Why?

2. How do you prevent overloading a user story with technical implementation details (like API logic)?

3. How would you coach a junior BA on whether this should be one story by itself or apart of another story that handles the entire transfer form?

Practicing BA takeaway:
You think beyond writing — into architecture, governance, and scalability.