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.
We track our work on a weekly (sprints) and monthly (epics) basis to keep track of time. This way, we avoid stretching elementary tasks over time and we’re compelled to monitor our progress towards reaching our goals.
We define our goals as Epics. Epics are a set of tasks defined to fulfil our goals and duties. We review and plan our Epics on a monthly basis during Epics Review and Planning sessions.
We split our work into tasks that are scheduled in weekly sprints. During a sprint, we agree to complete certain tasks within a week. We review and plan our sprints on a weekly basis during the Sprint Review and Planning sessions. We should stick to the weekly occurrence of these sessions even if it means dragging tasks into the next sprint. However, we should question the relevance of a task, if it were to be dragged from sprint to sprint repeatedly.
Company-wide information sharing.
Everyone is held accountable to everyone and everyone should be able to have an insight on what’s happening in every company project or section. Therefore, weekly and monthly Loom videos will be shared inside every section and project channels on Slack with Sprint and Epics Review and Planning sessions recap. Furthermore everyone can speak his mind for any matter by submitting suggestions to any project or section. Requests will be reviewed by the project/section manager and discussed on a weekly basis to possibly make it to the sprint planning.
Projects are detailed in features (user stories) and divided in Sprints during which specific tasks have to be completed and made ready for review in a set period of time.
- We use an Airtable board for each project to track Sprint Progress.
- 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 are software features descriptions written in an informal and natural language.
- 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.
- 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.
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.