Linear Method
The Linear method is our approach to product building that we follow on our own team.
It's helpful to know since it influences how we design the app and explains why the features work the way we do. We recommend checking out our in-depth articles on the Linear Method but here's a quick summary and visual guide.
Write issues, not user stories
The only requirement when creating issues in Linear is to add a title, team, and status like backlog or todo. This lets you create issues fast without it taking away from your core work. We don't think creating issues should be a chore and we don't write user stories.
When writing issues we break them down as small as possible and assign them to a single owner. We think that's really important. If multiple people are involved, we'll break down the issues into sub-issues and then assign those. For the most part, everyone on the team writes their own issues or if they're assigned an issue, gets to decide how to execute it.
Prioritize projects
Focusing on project-related issues creates a natural bias for us to spend our time on features that improve the product or level up the user experience in meaningful ways. Without the focus it could be easy to work on issues that didn't move us toward our goals.
Roadmap
We work off of a company roadmap so we're aligned on direction and priorities. We break this company roadmap down into smaller, thematic roadmaps that are tied to certain product areas (e.g. mobile) or initiatives (e.g. improve core user experience). Projects can be part of one or multiple roadmaps.
Work in cycles
While projects reflect our focus and priorities for the quarter and product generally, we use cycles to figure out what specific issues to work on during the week or weeks.
Cycles are similar to sprints but they don't end in a release or have a specific goal. They're a container that helps us choose and prioritize the issues we work on in a given period of time.
On our team, we work in 1 or 2-week cycles. Most work in a cycle will be tied to projects but we do mix in bugs, quality improvements and user requests which are filed to a backlog, which usually amount to about 10-20% issues done.
Cycles don't have deliverables or end in a release. You simply do the work you can and any work not completed gets rolled over to the next one. We don't overload cycles and we design them to be flexible.
We leave it up to individual team members to manage their time and decide what issues to prioritize within the cycle. We've also set up automations in team settings to minimize actually having to update issues or do much cycle planning.
We don't expect to complete cycles 100% or plan perfectly. We expect new bugs to come up as well as unexpected or opportunistic work, too, which means issues will get moved around and the scope line will creep up. That's a tradeoff we're okay with. We're aggressive about reporting bugs or issues and try to fix bugs immediately, since it reduces technical debt, keeps product quality high, and reduces time spent answering customer support questions.
Changelog
We release work continuously and summarize it weekly in a changelog.
The public changelog keeps us accountable to shipping a core feature or improvement each week without creating unrealistic or unhelpful pressure to push out features before they're ready. It's also a great way to celebrate work and share it with our community. This creates healthy balance and accountability since we don't usually set project deadlines and cycles aren't tied to releases. We share more about writing changelogs here.
Those are the most important things to know about the Linear method and how we work. Dive deeper into the Linear method on our website.