Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

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.

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

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. 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):

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

  • No labels