DigI:Scaling DigI solution Workshop with Digital Oxygen

From its-wiki.no

Revision as of 17:43, 27 July 2019 by Josef.Noll (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Digital Inclusion (DigI)
Home Overview Tanzania DRC Publications About us
English-Language-icon.png


DigI:Scaling DigI solution Workshop with Digital Oxygen

Title DigI:Scaling_DigI_solution
Place Egerner_Höfe@Rottach_Egern
Date, Time 2019/07/12, -13July2019
Contact Person Alexandra Ullmann
Participants Alexandra Ullmann, Tobias Woldrich, Hendric Tronsson, Nicolas Bell, Axel Meiling, Marianne Fichtl, Gerdi Stoppel, Josef Noll
related to Project DigI, BasicInternet
this page was created by Special:FormEdit/Meeting, and can be edited by Special:FormEdit/Meeting/DigI:Scaling DigI solution Workshop with Digital Oxygen
Category:Meeting


Agenda

Main goal was to discuss scalability of the solution, addressing a.o.

  • Political dimension: Mission concepts, approach & staffing, communications, strategy
  • Build an organisation that allows the experts to focus on one topic
  • Establish a leadership- and organisations-concept
  • Create written input to vision, goals, epics, features and user stories
  • Technical solution: too complicate for local self service
  • Standard: how can one define a solution that is technologically viable, solved by algorithms or protocols, and commonly applicable
  • Financial: Current focus is on technical and political

Organisational structure

What is the leadership-/organisational structure to involve ~300.000 People around the globe in Contributing to Connect the Unconnected

  • how are communities like Wikipedia, Linux Foundation, Red Cross, ... achieving the goal?
  • For smaller communities: Letsact (App), NGOs...

Which tools/methodologies might be appropriate?

Discussion is moved to LinkedIn: https://www.linkedin.com/feed/update/urn:li:article:8406580922138009288/ (and Danica will drive towards her network)

Regarding technical solutions

Good discussions with Thorsten, suggestion either

Suggestion: use the United Nations Platform to provide amp format

  • AMP — which stands for Accelerated Mobile Pages — was introduced by Google in October of 2015. AMP is an open-source custom web development framework created to speed up the loading time of web pages on mobile devices. Read more at: https://devopedia.org/accelerated-mobile-pages

About Vision, Goals.... user stories

Taken from software development, e.g. https://luis-goncalves.com/epic-user-story-task/

Epics

Epics are usually broad in scope, lacking in details, and are meant to be split into multiple, smaller stories before they can be worked on.

Important guidelines when creating an epic:

  • Create epics that managers and executes would want to track.
  • An epic could be a product feature, customer request or business requirement.
  • Let your organisational culture dictate the size of your epic.
  • Epics should not take too short or too long to complete.
  • Burndown charts can be used to measure epics and give an actual and estimated amount of work to be done.

User Story

The User Story is simply the list of items that need to be done within a project. Think of it as a to-do list. Important guidelines when writing a user story:

  • User stories are short, simple descriptions written throughout the agile project.
  • Although it is owned by the PO, anyone can write the user story.
  • It is expressed in plain language so the customer can understand what the final product is all about (in case of software, what it should accomplish).
  • It answers the ‘who’, ‘what’ and ‘why’ of a project in a simple language.
  • User stories serve as the ‘building blocks’ of the sprint.

Example

  • As a user, I want to migrate all my data backup in a cloud system to free up my device.

Tasks

Below each epic is a more detailed set of user stories. And for those stories to turn into workable components, the team has to identify and sort tasks.

Stories are decomposed into tasks. Tasks are grouped according to:

  • Not started – the tasks that are yet to be worked on.
  • In progress – tasks that the Scrum team are doing.
  • Done – tasks that are completed.