Using Notion

The secret to performance is perfectly sharpened processes

Overview

All of our tech work is made visible in Notion, our kanban tool. It is there that we detail what we have to do, prioritise it, monitor implementation progress, and ultimately mark features as completed and deployed.

The kanban methodology is great for everyone as we use the tool both as a personal productivity helper, to report on what we are doing to ensure everyone is progressing at the same pace, and also ensure that no conflicts arise due to people working on the same code area at once.

Perfect Notion cards

We put a lot of love in shaping perfect Trello cards, as we know that this is the way that fellow team members will be kept up to date about what we do - our cards make our work visible. In particular, we want to facilitate the job of our peers that will be conducting peer reviews by providing them with everything that's needed for this.

So here's a list of what a good Trello card should look like, including the essentials and additional data depending on its context. We strive to stick to these guidelines.

Checklist OUTDATED

All cards

Essentials:

• Team member attributed

• Label(s) attributed

• Explicit title in English (see writing good titles)

• Link to GitHub Pull Request (except if the card is part of a broader family of cards, where 1 key card holds the link to the Pull Request). If several repos are impacted, provide 1 link per repo, with the title of the repo in markdown above.

Nice-to-have:

• Description of the context in the details

• Link to the Google Slides with business specifications

• Status updates in the comments for long-lasting cards

• Link to associated documentation

• Explanation of why tests have failed (in the case of usual suspects)

Avoid:

• Pictures used as card cover

• User details (name and other) explicitly stated - we use IDs and links instead

• Documents stored in the card - we use links to the Drive instead

• CSV or other data extracts stored in the card - we use links to the Drive instead

Front-end changes cards

• Snapshot BEFORE the change

• Snapshot AFTER the change

Bug cards

• Link to relevant Sentry issue

• Link to Slack message in IT helpdesk channel (if relevant)

Deployment cards

• Explicit description of the tasks that should be run at deployment time (e.g. cap production strike:my_script)

• Explicit description of the dependencies of the scripts (e.g., first deploy A then B)

• Follow-up card for cleaning of the scripts if they are one-off operations

Writing good titles

We usually stick to the following naming convention: APP - Domain: Issue, for example:

• SW - Motorbike: policy owner amendments

• Ardor - Unpaids: semi-automated mail sending

• Cards API - Baloise: improved errors handling

Choosing relevant labels

We strive to categorize our cards with the relevant labels, so that we can perform analytics on them. Cards should always include at least 1 colored label (e.g. Products & Services / Back-office) and often 1 or more grey labels (e.g., Motorbike, Car). The labels indicate the nature of the work to be done (integration, refacto, front-end) as well as the broad applications domain where this work happens.

Various

• Zoom out to get the big picture view, ideally with all columns visible on your browser screen

• Do NOT filter only your own cards all the time: we work as a team and it's important to know what the others are up to and potentially jump in to help them