Key points of this lesson, in order.
Writing Jira User Stories for Payments
What you will learn
Your objective. By the end of this lesson, you will be able to explain writing jira user stories for payments. A user story is a short description of a feature written from the perspective of the person who needs it, and it is the unit of work that agile payments teams build, test and release.
Why it matters. For payments, the role might be a payment operations officer, a corporate customer, or a compliance analyst.
Chapter objective: Learner applies business analysis techniques to a payments project, writing requirements, user stories, acceptance criteria, and a traceability matrix for a real payment feature. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.
Key learning points
- User story
- Stories: grouped under epics
- Acceptance criteria
- Worked example
- Acceptance criteria for this story
- Two more criteria
Key terms
Charge bearer: A code that states who pays the charges for a payment. In ISO 20022 the values are DEBT for debtor, CRED for creditor, SHAR for shared and SLEV for service level.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Clearing and settlement timeline showing Writing Jira User Stories for Payments.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Read the ISO 20022 migration message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
A product owner must prioritise two stories: one adds a new payment rail, the other fixes the reconciliation break report. The break report affects daily operations. How should the owner decide?
Takeaway and next step
What to remember
These five criteria give the developer a precise target and the tester a precise checklist, and the story is only marked done when all five pass in the test environment.
Map the message fields from this lesson in the mapping workbench.
Builds on "Business Rules and Processing Conditions".
Transcript and full text
Show transcript
A user story is a short description of a feature written from the perspective of the person who needs it, and it is the unit of work that agile payments teams build, test and release. The standard format is simple. As a named role, I want a named capability, so that I get a named benefit. For payments, the role might be a payment operations officer, a corporate customer, or a compliance analyst. The benefit must be real and measurable, such as reducing manual repair work or meeting a regulatory deadline, because a story without a clear benefit is hard to prioritise. Stories are grouped under epics, which are large bodies of work that span several sprints. An epic for ISO 20022 migration might cover the conversion of all outward SWIFT payments from MT format to pacs.008, and it would contain dozens of stories. One for the field mapping, one for the validation rules, one for the exception handling, and one for the reporting. Each story is small enough to be completed in a single sprint, and each one has acceptance criteria that define exactly when it is done. Acceptance criteria are written in the Given, When, Then format, which makes them testable. Given describes the starting state, When describes the action, and Then describes the expected result. A good criterion is specific enough that a tester can run it without asking the analyst a follow-up question. For example, given an MT103 with a valid beneficiary IBAN, when the message is converted, then the pacs.008 must contain the same IBAN in the creditor account identification field. Vague criteria such as the message should convert correctly are not acceptable. A worked example makes the format concrete. Consider the story. As a payment operations officer, I want the system to convert an outward MT103 into a pacs.008 message automatically, so that cross-border payments meet the ISO 20022 standard without manual intervention. The story belongs to the epic called ISO 20022 Migration for Outward Payments, it is estimated at five story points, and it has a clear definition of done. The conversion runs in the test environment, all acceptance criteria pass, and the mapping document is updated. The acceptance criteria for this story cover the main mapping, the edge cases and the failure paths. First, given an MT103 with field 32A value date 15 November 2024, currency USD and amount 125,000, when the message is converted, then the pacs.008 must carry the same value date, currency and amount in the instructed amount field. Second, given an MT103 where field 50K contains the ordering customer name and account, when the message is converted, then the debtor name and debtor account in pacs.008 must match exactly. Third, given an MT103 with an invalid currency code, when the conversion is attempted, then the message must be rejected to the repair queue with the error code INVALID_CCY. Two more criteria complete the story. Fourth, given an MT103 with field 71A set to OUR, when the conversion runs, then the pacs.008 charge bearer must be DEBT, which is the ISO 20022 equivalent of OUR. Fifth, given a converted pacs.008, when the message is validated against the ISO 20022 schema, then it must pass with zero schema errors. These five criteria give the developer a precise target and the tester a precise checklist, and the story is only marked done when all five pass in the test environment.
A user story is a short description of a feature written from the perspective of the person who needs it, and it is the unit of work that agile payments teams build, test and release. The standard format is simple. As a named role, I want a named capability, so that I get a named benefit. For payments, the role might be a payment operations officer, a corporate customer, or a compliance analyst. The benefit must be real and measurable, such as reducing manual repair work or meeting a regulatory deadline, because a story without a clear benefit is hard to prioritise.
Stories are grouped under epics, which are large bodies of work that span several sprints. An epic for ISO 20022 migration might cover the conversion of all outward SWIFT payments from MT format to pacs.008, and it would contain dozens of stories. One for the field mapping, one for the validation rules, one for the exception handling, and one for the reporting. Each story is small enough to be completed in a single sprint, and each one has acceptance criteria that define exactly when it is done.
Acceptance criteria are written in the Given, When, Then format, which makes them testable. Given describes the starting state, When describes the action, and Then describes the expected result. A good criterion is specific enough that a tester can run it without asking the analyst a follow-up question. For example, given an MT103 with a valid beneficiary IBAN, when the message is converted, then the pacs.008 must contain the same IBAN in the creditor account identification field. Vague criteria such as the message should convert correctly are not acceptable.
A worked example makes the format concrete. Consider the story. As a payment operations officer, I want the system to convert an outward MT103 into a pacs.008 message automatically, so that cross-border payments meet the ISO 20022 standard without manual intervention. The story belongs to the epic called ISO 20022 Migration for Outward Payments, it is estimated at five story points, and it has a clear definition of done. The conversion runs in the test environment, all acceptance criteria pass, and the mapping document is updated.
The acceptance criteria for this story cover the main mapping, the edge cases and the failure paths. First, given an MT103 with field 32A value date 15 November 2024, currency USD and amount 125,000, when the message is converted, then the pacs.008 must carry the same value date, currency and amount in the instructed amount field. Second, given an MT103 where field 50K contains the ordering customer name and account, when the message is converted, then the debtor name and debtor account in pacs.008 must match exactly. Third, given an MT103 with an invalid currency code, when the conversion is attempted, then the message must be rejected to the repair queue with the error code INVALID_CCY.
Two more criteria complete the story. Fourth, given an MT103 with field 71A set to OUR, when the conversion runs, then the pacs.008 charge bearer must be DEBT, which is the ISO 20022 equivalent of OUR. Fifth, given a converted pacs.008, when the message is validated against the ISO 20022 schema, then it must pass with zero schema errors. These five criteria give the developer a precise target and the tester a precise checklist, and the story is only marked done when all five pass in the test environment.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.