Payments Training Hub

LAB-05: Deliver an Instant Payments Feature in Three Sprints

Agile delivery

An instant payments feature must reach customers in weeks, not months, and the work must be split into pieces that a team can build, test and release in short sprints. In this lab you plan and run the delivery of an instant payments feature across three two-week sprints. You will break an epic into features and user stories, write acceptance criteria in plain language and in Gherkin, build and prioritise the backlog, and plan the sprint goals, the stand-ups, the reviews and the retrospectives. You will also define the RACI for the release and the definition of done that decides when a story is truly finished. By the end of the lab you will have a delivery plan that a product owner, a scrum master and a development team can execute together.

0 of 5 steps done. Tick each step as you finish it, your progress is saved in this browser.

  1. Start from the business goal: retail customers can send instant payments of up to 10,000 dollars in under a minute, 24 hours a day. Break the goal into an epic, then into features for account validation, payment initiation, status reporting, exception handling and reconciliation. For each feature, note the value to the customer and the dependency on other features, for example status reporting depends on initiation. Agree the epic scope with the product owner and confirm that business bulk payments are out of scope, so the team does not drift.

  2. Write the user stories in the standard form: as a customer, I want to send money instantly, so that it arrives in seconds. Keep each story small enough to finish in one sprint, and give it a clear business value. Write acceptance criteria for each story in plain language, then rewrite the key ones in Gherkin, so that testers can automate them. Review every story with the product owner and the test lead, and split any story that is too large before it enters the backlog.

  3. Order the backlog by value and dependency, not by ease. Put the highest value stories first, and flag any story that is blocked by another team, such as the screening service upgrade. Estimate each story with the team using story points, and record the estimate next to the acceptance criteria. Agree the definition of ready, so that a story only enters a sprint when its criteria are clear, its dependencies are known and its test data is available. Publish the backlog where the whole team can see it.

  4. Plan three two-week sprints, each with a goal, a set of stories and a clear outcome. Sprint one delivers account validation and limit checks. Sprint two delivers initiation and status reporting. Sprint three delivers exception handling and the go-live checks. Note the dependencies between sprints and the risks, such as the screening service being late. Run a daily stand-up of 15 minutes, a sprint review at the end of each sprint with the product owner, and a retrospective where the team agrees one improvement to carry into the next sprint.

  5. Write the RACI for the release, naming the product owner as accountable for scope, the scrum master as responsible for the process, the business analyst as responsible for the stories, and the test lead as responsible for the exit criteria. Agree the definition of done: code reviewed, unit tested, acceptance criteria passed, documentation updated, and the story demonstrated in the sprint review. Record the release criteria, including a 99 percent success target and a rollback plan if it falls below it. Get the whole team to sign the plan.

Templates.

Worked example. Willowbank, a fictional bank in Sydney, is delivering an instant payments feature in three two-week sprints so that retail customers can send money in under a minute. Sprint one covers account validation and limit checks, sprint two covers the payment initiation screen and the real time status updates, and sprint three covers the exception handling, the daily reconciliation report and the go-live checks. The product owner writes a user story for a customer who sends 500 Australian dollars to a friend: as a customer, I want to send money instantly to a contact, so that the money arrives in seconds. The acceptance criteria state that the payment completes in under 60 seconds, the sender sees a confirmation screen, and a failed payment returns a clear message with the reason. In sprint two, a story for duplicate prevention fails its acceptance criteria because a double tap on the send button creates two payments. The team fixes the idempotency handling, retests, and the story passes. At the end of sprint three the feature is released to 10 percent of customers, the success rate is 99.4 percent, and the retrospective agrees to add a load test to the definition of done for the next release.

Deliverables.