v1.5 - last updated on 31/01/2020

We are a remote by default team where people need to work without missing out.

For that purpose:

  • We use asynchronous communication as a start.
  • We write everything down.
  • We use Slack for all internal communications.
  • We only jump to a synchronous video call if needed.
  • All written communication and video recordings happens in English.

Project Management.

We define all the projects requirements and hypothesis as User Stories. We then split our work into weekly Sprints.


  • A Sprint is a set period of time during which we agree that planned work has to be completed and made ready for review.
  • We use an Airtable board for each project to track each Sprint progress.
  • We agree that all changes to the Sprint Backlog must be approved by the PM.
  • We agree developers shall not pull stories out of the Sprint Backlog and begin working on them.

User Stories.

  • User Stories are software features descriptions written in an informal and natural language from the perspective of the final-user
  • As a < type of user >, I want < some goal > so that < some reason >.
  • User Stories are written on Airtable records in the Features table and are used to plan and test the work.
  • PM is responsible for creating the backlog and prioritising user stories.
  • User Stories should always have acceptance criteria to test that the solution meets the need of the final-user.
  • We agree to not “throw cards over the wall” but rather discuss with the team and inform all the team on Slack if there is something getting in the way.


We hold a Sprint Planning Meeting at the beginning of the Sprint with the following agenda:

  • We agree upon exactly what work will be accomplished.
  • We work as a team to ensure that
    • stories are well defined.
    • stories will be estimated.
    • stories will be prioritised.

During a Sprint.

  • We agree to only work on what is in the current Sprint.
  • We will not ignore the sprint or the priority ranking.
  • PM is available to answer any requests for information on product features.
  • If work for the current sprint has been completed early, or conversely - can’t be completed for some reason, a team discussion must take place.
  • Trello Cards Sprint lifecycle: Sprint Backlog > In Progress > To Review > Done.
  • We agree to follow the process of moving a card through it's life cycle so that the Trello board always reflects the most accurate information.
  • Stories are considered completed, only when PM agree that the acceptance criteria of a story have been met.
  • We hold Daily Stand up check-ins on Slack to track progress and be proactive.
    • Participants come prepared to answer the three questions.
      • What have you completed since the last meeting?
      • What do you plan to complete by the next meeting?
      • What is getting in your way?
    • Unless otherwise stated on Slack, will always take place from Monday to Friday at 2p.m. CET unless defined otherwise.

Retrospective & Review.

  • We hold a Review and Retrospective Meeting at the end of the Sprint with the following agenda:
    • Global Sprint Review.
      • We demo the potentially shippable increment.
      • We assess if Sprint Goal has been reached.
      • We suggest eventual updates in Product Backlog.
    • During retrospective we inspect the sprint to find room for improvement and change or build for the better.
      • We Capture what went wrong during the sprint.
      • We Capture what went right during the sprint.
      • We Capture what the team can do to improve.
    • Peer Review: we review our team members.

Individual Task Management.
  • We’re free to plan the weekly tasks we have been assigned to. We should coordinate planning with collaborators when necessary.
  • We should use our favorite task management tool to manage our daily workload.
  • We should integrate our personal task management tool with the Airtable boards we're part of to automatically receive tasks that we have been assigned to.

  • We hold meetings for:
    • Sprint Planning & Review.
    • Epics Planning & Review.
    • Informal discussions.
  • Should a team member have a conflict, she notifies and updates the team in advance.

As a Team.
  • We agree to have conversations and to start them as early as possible.
  • We agree to be punctual for deadlines and meetings.
  • We agree to make & work on commitments as a team.
  • We agree to ask for help, or conversely - to volunteer to help.
  • We agree to review our processes and make changes as necessary.
  • We agree to speak out our opinion.
  • We agree to be transparent.
  • We agree to “play along” by the present handbook.

Work Hours.
Meetings exlcuded, we're free to choose working hours as long as things get done and deadlines are met.


This handbook is subject to constant evolution. Team members will be notified when changes are made. Feel free to suggest improvements & clarifications.