Using Notion

Search…
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
​
​
​
PROCESSES & TOOLS - Previous
Our Kanban ethos
Next - PROCESSES & TOOLS
Perfect Notion cards
Last modified 1yr ago
Copy link
Outline
Choosing relevant labels
Various