| Info |
|---|
This workshop was conducted before the MVP - Meeting/Workshop preparation . Please consider this workshop as a pre-workshop but not the action workshops that will be conducted in the future. |
\uD83D\uDC65 Participants
\uD83E\uDD45 Agenda / Goals
The first workshop will be only 2 hours. Therefor not all the agenda needs to be covered.
...
| Info |
|---|
Strikethrough areas will be discussed next workshops |
Recap of the Project Vision and Goals
Definition/Vision
Existing definition:
The USCT MVP is built based upon the technical sandbox and the USCT simulation. It’s intended to enable a vertical penetration of GovStack based on an idealised journey of the use case "Unconditional Social Cash Transfer" in order to make a common exemplary journey accessible to all teams and groups. With the help of this, they can further develop and test their individual developments and concepts. It is additionally serving as a technical proof of concept and example implementation for the GovStack community.
...
The USCT MVP is built based upon the technical sandbox and the USCT simulation. It’s intended to enable a vertical penetration (re-define vertical penetration) of GovStack based on a slice of the journey of the use case "Unconditional Social Cash Transfer" in order to make a common exemplary journey accessible to all teams and groups. It is a technical proof of concept and example implementation for the GovStack community.
User Group:
The primary group is technical people within the GovStack community
Also for showcasing a concrete product for the other members.
Goals of the MVP
Primary Goal:
Creating a technical proof of concept of USCT use case MVP for showcasing Govstack approach to Govstack community.
Secondary Goal
Documenting in detail the development processes
Other Goals:
Horizontal collaboration with BBs teams for USCT MVP
Showcasing BBs roles within the USCT MVP
To see/learn the interaction between BBs for USCT MVP
Understanding and learning the extent of complications and scope of GovStack approach application process.
It will show the pain points and missing part during the development process to provide insight to Govstack Community. (There is always a risk to fail to implement therefor these learning can be highly beneficial)
Scope (Draft):
| Note |
|---|
Draft |
?The application will be placed into GovStack execution environment
Outcome / Decisions:
New Definition of the MVP was created
The goals created
The scope of the MVP decided to be discussed with the customer
Content will be created together with developers and UX team
UX designers will provide the possible User Flow and skeleton wireframes+ Possible high level content
Developers will provide poissible data, limitations of the BBs and possible content for the flow + Possible high level content
Action Items
- 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)
Revisit set goals and check relevance
Set up action plan
What and how to share this MVP outline to stakeholders?
(“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.”