MVP - Meeting/Workshop preparation

Owned by Martha Vasquez
Last updated: May 25, 2023
4 min read

It makes sense to postpone the client meeting, until Jonas is back and the new Tech-Lead had the opportunity to dive into the project. (possible date 29th of May)

  • Set a 2h workshop to clarify all meta info related topics and update Nico in regards of the MVP decisions the DEV team made

  • Show the agenda to team before and discuss some topics before the client meeting

  • We agreed upon that we need to clarify the meta questions, to set and manage expectations

 

Meeting is set on the May 22, 2023 for 2 hour.

Participants: @Meelis Zujev (Deactivated) @Vasil Kolev @Martha Vasquez @Oleksii Danyliuk @jarkkohyoty @Vladislav Todorov

Agenda:

  • Set MVP vision or decide if Client should set the vision

  • Revisit and shorten the definition of the MVP so its easier to understand

  • Revisit the happy flow and decide on a clear set of steps and requirements

    • Define extensibility of the MVP

  • Revisit goals and clarify following issues and discuss if they are relevant for the client or only internal goals

  • GitBook for Documentation - does it make sense for UX as well?

  • How can we involve Nico more into the project so he feels informed enough and can intervene when necessary

Core feature of the MVP will be to demonstrate building blocks

 

(New) MVP Vision:

Our focus is on user with a technical background within the GovStack community.
The goal is to showcase the how the infrastructure and components are working together to setup business scenario under the country engagement.

Vision Example:

“Our focus is on (Persona outcome). We think it delivers (Benefit) to (Persona). This benefit will be measured by (KPI or Metric)”

(New) MVP Definition:

The USCT MVP is built based upon the technical sandbox and the USCT simulation, showcasing key learnings and demonstrating the process of authenticating and enrolling data into a specific system. It focuses on simplified parts of the "Unconditional Social Cash Transfer" use case journey. It is a technical proof of concept and example implementation for the GovStack community.

Happy Flow:

  • definition of the flow steps and what to create or prepare (Wireframes)

  • define what we’ll present to the client

Updated graph and infos can be found here: https://github.com/GovStackWorkingGroup/sandbox/blob/happy-flow-ui-part/spec/happy-flow.md

MVP Extensibility:

  • What is really the minimum of it?

  • Would it make sense to define the next iterations of the MVP?

  • Should we create a possible roadmap?

  • If we don’t want to have a roadmap, maybe we can define milestones with a presentation so Nico gets an overview

 

Decision and next steps: @Martha Vasquez add links here

implement “minimum minimum” viable product (information mediator and payment application)
new building block candidate or feature for a specific app into the flow
expectation is September/october
next “Happy minimum” viable product (promised only payment bb)
Interface will show the minimum amount of info which showcases the usage (simple interface) of the MVP and show that “it’s working”
Next sprint (in 2 weeks) a basic roadmap will be presented
Jira Roadmap (possibly outdated)

Possible Data/content for the wireframes:

  • wireframe content can be based upon another app (e.g. own banking payment app)

  • content will be backed up by proper apis

Possible option to show info:

  • two personas one entity; Government > fill in info, provides info for the other entity

  • Entity list, search, way to distinguish when you're logged in, which one is represented atm

  • Two perspectives:

    • Government

    • Applicant

Goal relevance:

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

 

Additional goals

Question

Answer/ToDo

Additional goals

Question

Answer/ToDo

horizontal collaboration with BBs teams for USCT MVP

  • how does this look like?

 

Showcasing BBs roles within the USCT MVP

  • How does this look like?

  • How should we showcase BBs roles within the USCT MVP?

 

To see/learn the interaction between BBs for USCT MVP

  • in need of an interface?

 

Understanding and learning the extent of complications and scope of GovStack approach application process.

  • is this really the goal? Shouldn’t it highlight that it’s not complicated?

 

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)

  • expectation management to the users

 

GitBook documentation

  • Would it make sense for the Design-Team to use GitBook as well?

    • If yes, why?

  • Do’s and Don’ts

  • What will be documented in confluence and which info in GitBook?

    • e.g. confluence can be used for meeting notes and to document internal decisions

    • GitBook could be used as a summary to communicate

How can we involve Nico more into the project so he feels informed enough and can intervene when necessary?

Action Items (last meeting)

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