Versions Compared

Old Version 4

changes.mady.by.user Kibuuka, Arnold

Saved on

compared with

New Version Current

changes.mady.by.user Kibuuka, Arnold

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

🔗Meeting recording

\uD83E\uDD45 Goals

  • Follow up on Payments BB implementation with MIFOs.

  • Alignment around agile processes across different building block teams.

\uD83D\uDDE3 Discussion topics.

Item

Presenter

Notes

Clarification on Payments use cases.

Mauree, Venkatesen

  • The payments building block proposes to standardize the G2P use cases and make them generic so that they can be used for different types of G2P payments.

  • Simon EyreAlthough MIFOs will need to make some assumptions or choose to focus on specific information during the implementation of the software in the sandbox environment to properly reflect the use case, this will not limit what is being built. MIFOS is aligned on the specification level of being as generic as possible.

alignment around agile processes across different building block teams


Simon Eyre

  • Simon Eyre talked about his efforts to make the process more agile and discussed the importance of a product owner role and a system architect as well as single programme backlog, to help priorities actions, without which: -

    • The team is concerned about meeting expectations and objectives.

    • There is a lack of clarity around requirements at the API and sandbox levels, and who the ultimate decision maker is.

    • The need more processes to define how they interact with respective teams.

    • Simon spoke more about the need for these processes, and they need to decide which specific user stories to focus on.

  • Mauree, Venkatesen requested added that what is important is to build the payments building block functionality.

  • Satyajit Suri suggests that the team should not get lost in the details and should stick to some principles.

    • The sandbox should not drive the Govstack, and the focus should be on properly implementing building block candidate implementations as part of specifications.

    • The team should define their own backlog and sprints for implementing the payments building block and align with the sandbox team where necessary.

    • The focus should be on demonstrating the unconditional cash transfer use case.

    • The building block candidates have to be integrated with the sandbox, but they don't have to happen at the same time.

  • Mauree, Venkatesen The team will review the backlog and try to resolve any issues directly or with the help of other teams.

  • Vijay mentioned three key focus areas for the unconditional social cash transfer use case are:

    • Populating the account mapper

    • API functionality for the mapper

    • Simulation of bulk payment disbursement with a dummy payments file

...

✅ Action items

  •  Ed Cable , Simon Eyre to create a team page on Confluence that is similar to the sandbox team page and provides an overview of our team members and their respective roles and responsibilities. The goal is to enhance communication and collaboration among team members and provide transparency to external stakeholders who need to understand our team's composition and functions.
  •  Simon Eyre will have a follow up call with Steve Conrad to discuss more on the alignment around agile processes across different building block teams.

⤴ Decisions

  • The key focus areas for the unconditional social cash transfer use case are:

    • Populating the account mapper

    • API functionality for the mapper

    • Simulation of bulk payment disbursement with a dummy payments file