Versions Compared

Old Version 9

changes.mady.by.user Artun Gürkan

Saved on

compared with

New Version Current

changes.mady.by.user Jonas Bergmeier

Saved on

Key

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

...

  •  Discuss minimum scope (portal/registration/Log In phase with the customer)
  •  Learn about the expectations of the customer for creating the scope
    •  Do they expect this MVP application going to be accessible for everyone or it is only for the Govstack community? (Consider the Primary user group)
    •  Where the MVP will be running?
  •  Where is the application placed will be orchestrated?
    •  Is it going to be placed in the portal/sandbox? Consider BBs placement also
    •  Artun Gürkan Create a diagram regarding the possible scope version 1 and version 2 of the Jarkkos comment.
  •  The clear understanding of which building block is necessary for the user journey. Mapping the USCT MVP flow with BBs (Spesificly with the specifications)
  •  The definition will be revisited after the scope and terminology document will be changed accordingly

Follow Up

Participants

jarkkohyoty Vasil Kolev Oleksii Danyliuk Meelis Zujev (Deactivated) Martha Vasquez Jonas Bergmeier

Agenda

→ What’s your expectation? What are you longing for? What do we have to decide to continue to work on a Govstack MVP?

  • Meelis: What’s mutually aggreed MVP on technical manner, what would be implemented in timeline of 3 months?

  • Meelis: End of September is planned milestone for 2nd release

  • Oleksii: Clear steps from frontend regarding endpoints?

  • Vasil: Understand goal of MVP in terms of functionality - what is expected after 3 months? Who’s driving requirements and what is expected?

  • Martha: Check description from last time, integrate Nico

  • Jarkko: “Sell” this to Nico, extremely simple MVP is less than expected, we shouldn’t underdeliver, therefore set lower goals for MVP

    • Meelis: Move step by step in that sense ^^

  • Jarkko: How can we make this extendable?

  • Jonas: MVP mock vs. non-mock, who’s owning requirements of MPV?

  • Jarkko: We shouldn’t mock things - either we implement a BB or we leave it out.

  • Jarkko: We don’t have compliant BB implementation, guess that we’ll have payment in future. So payment and IM will be baseline we’ll start with. → that can be baseline promise, everything else can only be extension

  • Oleksii: Target (full) MVP is complicated, we can’t break it down, it’s too complicated (and not ready). “Superminimal”

  • Vasil: We should be really fast … Nico should be responsible for approving in a fast manner, very minimal impl. to showcase, we should ignore dependancy to other BBs, impl. mustn’t be sophisticated, fake impl. could allow us to implement reference implementation, going ahead with MVP would be pulling factor for other vendors - how to move forward supporting govstack but igonoring dependancies at the same time?

  • Vasil: Proof that payment process will go smoothly, provide ref. implementation

Goal Phase 1: Tangible implementation of USCT use case parts aligned with BB vendors (expected to be around payment and IM BBs).

Vasil: What’s the definition of mock?

(From previous meeting)

  1. Revisit set goals and check relevance

  2. Set up action plan

  3. What and how to share this MVP outline to stakeholders?  

  4. (“Superminimal”)

Action Items

  •  Review jarkkohyoty draft Jonas Bergmeier → what' implementable NOW? according to USCT and prepare for meeting on
  •  define phase 1 scope and scope of flow sequence for MVP release and general requirements for MVP implementation jarkkohyoty Vasil Kolev

“This MVP should be a technically-driven demo to showcase how the fraction of a possible real implementation of 'a Govstack' could look like. If we are mocking important functionalities there’s no benefit in doing it.”