How we use Linear to optimise our development workflow
Challenge
We’re a digital agency in Utrecht, The Netherlands. Six professionals make up the team of Reversed Digital: 4 UX designers and 2 full-stack developers. We use several tools to make our working lives easier, some of those tools are specifically used by either developers (like GitHub, VSCode or React) or designers (like Principle and IconJar) and some are more used throughout the company, like Figma and Slack. And like Linear.
When dealing with project issues, we ideally want everyone to be able to use the software that they carefully selected as part of their toolbox. Also, we’d like our fellow team members to be able to tune in on the state of issues that are relevant to them at any given moment. Additionally, we’d like the workflow of our issues to be supportive to our collective way of working, by providing a smooth flow of workflow states that supports uninterrupted focus when working on issues. Not something that distracts your focus and interrupts your flow for the sake of a system.
🙌 Linear 🙌
Linear is a lightning fast, fantastically designed issue tracker build by a team that strives to bring the magic back in software. It’s lead by designers and engineers with a history at Airbnb, Uber and Coinbase and backed by progressive giants like Sequoia and Index Ventures and people in leading positions at Figma and Expo. It’s pretty much the new kid on the block (a very well backed kid though) as it hasn’t released a production version just yet, but we’ve had the chance to use their tool in an early, but impressive state.
Linear lets you control the available workflow states for your issues and their order. It enables you collect issues in Cycles (much like agile sprints) and gives you full control over the interface using keyboard shortcuts 🤯. It also offers solid integration with tools like, you guessed it, Figma, Github & Slack (and Google Sheets & Zapier).
How we use linear to optimise our development workflow
Using Linear, we’ve created a workflow that is loosely based on SCRUM. Basically, this is the flow our issues sail through:
- Create an issue in Linear → Workflow state: Backlog
- Prepare issue for todo → Workflow state: Todo
- Process issue, create PR → Workflow state: In Progress
- Dev review → Workflow state: Dev Review
- Design review → Workflow state: Design Review
- PR merged → Workflow state: Done
Thanks to Linear’s integration with the tools we use (and our very own Reversed Housebot) these steps flow pretty much automatically. Let me show you:
1. Create an issue in Linear
We create an issue in Linear, the issue gets the default workflow state Backlog.
2. Prepare issue for Todo
Before an issue is ready to be processed, we’ve set up a couple of requirements. If applicable, we add links to relevant Figma files/sections in the issue body. Linear’s Figma integration creates a nice preview of the link, giving you a good idea of the scope of the issue at first glance. The issue gets assigned to one of our developers and we subscribe the relevant designers to the issue, allowing them to keep track of the issues comments and workflow state updates. Now our issue is ready to be processed and its workflow state is set to Todo.
3. Processing issue, create PR
When the developer begins processing the issue, he/she creates a feature branch on the Github repository and creates a Pull Request referencing the Linear issue in the opening comment. When we create a PR, we’re indicating that we’re building a feature that we wish to merge in the near future. When the developer requests a review from a colleague, it is assumed the developer thinks the code is production ready. When the PR is opened, Linear’s GitHub integration makes sure the referred issue’s workflow state gets set to In Progress.
Every PR gets deployed, we run a bunch of tests and then deploy the PR. Each deployment is unique, and its URL is generated using the project name and the number of the PR. Devs use these isolated environments for their dev reviews, designers use them for their design reviews. In order to make sure that both developers and designers have easy access to these environments, we created our own Reversed Housebot. This esteemed colleague generates a comment containing the link to the demo environment and places it on both the PR in GitHub (for devs) and the relevant issue in Linear (for designers & devs).
4. Dev review
When the developer wishes to merge the feature into the master branch, he/she calls for a review from a colleague in the GitHub pull request. When a review gets requested, GitHub integration in Linear triggers the next workflow state for our issue: Dev review.
5. Design review
When two developers believe the feature is indeed production-ready, the PR review gets approved. When this happens, our housebot is triggered again and sets the workflow state of the issue to Design review. The subscribed designer can then review the design of the issue using the link to the demo environment found in the comments of the issue. If the designer likes it, we can move on to the last step.
6. Merge PR
The quest of our issue has nearly come to an end. Everybody’s happy, everybody was able to use the tools they like and even our issue is happy, because it’s fully grown up now. It’s ready to conquer the world in production. The developer heads over to his PR on GitHub and merges it. Linear’s GitHub integration triggers the issue’s final state: Done.
That’s it. And we’re pretty happy with it. Do you have some tips for further improvements? Do you want to know more about our way of working? Drop us a line, we’d love to talk it through.
Want to learn more about Linear?
Want to keep track about what we’re up to? Join our newsletter and we’ll keep you updated!
