Versions Compared

Old Version 3

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.
Note

Draft

\uD83D\uDDD3 Date

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.

Discussed

  • Recap of MVP Definition, Goal and Scope

    • Define and highlight the problem the MVP aims to solve

    • Collaboratively define what the MVP means for the project and establish its scope and boundaries.

    • Scope

      • Primary Goals of the MVP

      • User Group / Possible Personas and Scenarios

        • Discuss user scenarios aligned with the problem the MVP aims to address.

        • Identify key user journeys or tasks that the MVP should support.

        • Discuss any specific considerations from a technical perspective (e.g., scalability, integrations) that should be factored in.

      • Discuss the core features and functionalities that the MVP should include, considering input from all participants.

  • Design and Development Collaboration, Planning next steps and roles

    • Presentation of the Wireframe planning and context

      • Discussion regarding how to define the content

        • add an additional layer to the BPMN regarding Data input and out/ which data is provided from BBs and how to cover other content

    • Collect feedback and suggestions from backend developers regarding technical feasibility and potential challenges.

    • Facilitate a discussion on trade-offs between design and development to ensure alignment and feasibility.

  • (Maybe) Feature Prioritization and Roadmap

    • Collaboratively prioritize the identified features based on business value, user impact, and technical feasibility.

    • Create a feature roadmap for the MVP, considering development dependencies and resource availability.

    • Discuss potential iterations or phases beyond the initial MVP release.

  • Adjusting BPMN diagrams

    • Decide documentation

    • Where to start? What are the limitations and considerations?

      • What is the most valuable and impactful area to start? UI, user flow or Building Blocks? Based on this collaboratively create the flow.

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.

Comments:

  • Meelis: MVP is not for the teams, they can not develop and test their individual developments.

...

Primary Goal of the MVP

  • Enabling a vertical penetration of GovStack for helping all teams and groups within Govstact to develop and test their individual developments and concepts

User Group: GovStack Teams

...

  • It is for more the technical personas to realize how it can happen

  • Jarkko: Main Goal is MVP is to provide technical proof of concept and example implementation for the GovStack community.

  • Martha: Maybe we should first focus on the persona.

New Definition:

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)

  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.”