This handbook defines how we work and collaborate as an all remote team. We do our best to define a collection of expectations, commitments and responsibilities to strive at creating a productive workplace. Any suggestions for improvement or clarification? Drop us a line at firstname.lastname@example.org.
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 excluded, we're free to choose working hours as long as:
we keep cristal clear communications,
things get done and deadlines are met.
We are a remote by default team where people working from different time zones 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 use Loom to share feedback.
We only jump to a synchronous video call if needed.
We hold synchronous video meetings for:
Weekly Sprint Planning & Review
All written communication and video recordings happens in English
Should a team member have a conflict, she notifies and updates the team in advance.
We manage our projects according to an iterative approach based on agile principles and the scrum framework. We want to be quick at delivering reliable products while including user feedback in the process.
We use an Airtable board for each Project to manage and track daily progress.
Airtable is our one source of truth to track the state of any Project.
All Project stakeholders including clients have access to the Airtable Project board to monitor progress.
Check out our template board applied to the Slack app as an example.
We define all Project requirements as User Stories.
User Stories are short product feature descriptions written from the perspective of the end user.
User Stories are written with the following syntax: As a < type of user >, I want to < some goal > so that < some reason >.
User Stories are written in the User Stories table on the Airtable Project board and are used to plan and test the Work.
User Stories are complemented by acceptance criteria: a list of conditions that a User Story must satisfy to be considered as done.
We agree to not throw User Stories over the wall but rather discuss with the team and inform all the team on Slack if there is something getting in the way.
The Product Owner is responsible for defining and prioritising the User Stories with the client while maintaining the conceptual and techical integrity of the features during the development process.
The Product Owner is responsible for recording Loom videos briefs that explain all acceptance criteria in pair with the corresponding mockups.
Work in a Project is not limited to User Stories.
Technical tasks, User Stories feedbacks, bug fixes, and other tickets are articulated as Tasks.
Tasks are written in the Tasks table on the Airtable Project board.
Developers are free to break down User Stories in elementary Tasks when working on them.
The Backlog is the primary list of Work (User Stories and Tasks) that need to get done. In other words it's the Project's "To Do" list.
We agree that all changes to the Backlog must be approved by the Product Owner.
We agree Developers shall not pull Tasks or User Stories out of the Backlog and begin working on them.
We split Work into Sprints.
A Sprint is a set period of time (1 or 2 weeks) during which a set amount of Work has to be completed and made ready for review.
Tasks and User Stories are managed sumultaneously in a Sprint but in their own table.
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.
All acceptance criteria are reviewed together to ensure that we all understand what needs to be done.
We work as a team to ensure that
User Stories and Tasks are well defined.
User Stories and Tasks will be estimated.
User Stories and Tasks will be prioritised.
We agree to only work on what is in the current Sprint.
We will not ignore the Sprint or the priority ranking.
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.
Sprint Work lifecycle: Todo > In Progress > QA > To Review > Done.
Prior to Sprint Planning, the Product Owner is responsible for:
detailing all acceptance criteria;
gathering all necessary assets (mockups);
recording Loom video briefs;
Prior to Sprint Planning, everyone should check out the Loom video briefs of the remaining User Stories in the current release.
Developers should not work on more than two User Stories at a time, until it moves to “QA”.
Developers should only move User Stories or Tasks to "QA" once he or she deems it ready to be reviewed. (This doesn't apply for personal Tasks).
Developers should commit their Work once turned to "QA". (see development guidelines bellow)
The QA Developer is responsible for making a code review once a User Story or Task reaches QA.
The QA Developer should mark User Stories and Tasks as "To Review" once they passed QA.
The Project Manager is reponsible for reviewing User Stories that are "To Review" in a timely manner.
The Project Manager should write down all User Testing feedback and bug reports as Tasks within the same Sprint.
Task title should be consice, self-explanatory and structured to be easily spotted.
Task notes should be used to further explain the issue (if necessary).
Loom videos should be used to better illustrate an issue (if necessary).
Task priority should be defined in regard to the issue's impact on the UX (if product is live).
The Project Manager is responsible for processing client feedback and reproducing reported bugs before adding them as Tasks (cfr. Customer Tickets)
The Project Manager should mark User Stories and Tasks as "Done" once the acceptance criteria of a story have been met.
The Project Manager is available to answer any requests for information on product features.
Daily Stand-ups are 10min long daily meetings to keep the Team (Product Owner, Project Manager and Developer(s)) informed and connected
Daily Stand-ups highlight Sprint progress and help flag blockers.
We hold Daily Stand-ups for each project every day at 11:00 am (unless planned otherwise) from Monday to Friday.
The Daily Stand-up schedule for each Project is announced at the begining of each Sprint.
Daily Stand-ups are held on quick calls (unless plannned otherwise)
Participants come prepared to answer 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?
The Project Manager should right down a brief summary of the Daily Stand-up in the Project's Slack channel in form of short answers to each question.
We may schedule demos at the end of a Sprint where the Project Team demos the potentially shippable increment. The Team then assess if Sprint goals have been reached and suggest eventual updates in Product Backlog.
We may hold Retrospective Meetings at the end of a Sprint to inspect the past 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.
Tasks breakdown (daily workload) can be managed in any task management tool (even though it can be done in Airtable) as long as Airtable stays the one source of truth at any given time.
Our current Work progress should be reflected in Airtable on a daily basis.
We should coordinate planning with collaborators when necessary.
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.
Project stakeholders can give feedback and report bugs through a Airtable Tickets Form.
The Project Manager is reponsible for clarifying the ticket with its author through the dedicated chat in the Airtable ticket record. (use user mentions (ex: @username) to notify someone through the chat)
The Project Manager should reproduce bugs reported in a ticket and create a new bug report task in the Tasks table. The bug report should be self explanatory (note, screenshot, or Loom recording) so that the Developer can easily understand and tackle the issue.
After creating the bug report Task, the Project Manager should mark a Ticket as processed (checkmark field in the Tickets Table) and leave the corresponding Task airtabe record URL in comment for followup by its author.