Linear Method
tags:: Productivity Software Project Management
Source
Software development method used by https://linear.app. Much simpler and sense-making than Agile.
Principles
Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you.
Create momentum—not sprints.
Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work.
Practices
Set monthly, quarterly and/or annual roadmaps.
Connect daily work to larger goals with projects.
Keep a manageable backlog. You don't need to save every feature request or piece of feedback. Important ones will resurface.
Mix feature and quality work.
Specify project and issue owners.
Use feedback as research library when developing new features. Try to spot trends.
The best creators often have talent for both design and engineering.
Write a backlog.
Don't Write User Stories, But Tasks
The point of writing an issue is to communicate a task.
Problems with User Stories
We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work.
They’re a roundabout way to describe tasks, obscuring the work to be done.
One reason user stories are complicated and difficult to scope is because they bring what should be product-level details into the task level.
Do This Instead
Write clear, simple issues that describe tasks in plain language. Write your own issues.
Discuss the user experience at the product and feature level, not the task level.
- Describe concrete tasks or problems
- Write clearly and directly (easy to read on a board)
- Write only what you need
- Write your own issues
- When you write your own issues, it forces you to think through the problem at a deep level. This creates space to come up with even better approaches and makes it easier to spot shortcuts or missing parts in the plan.
- Keep user experience discussions at the product level
We discuss a feature or project deeply before deciding on an implementation plan. The project owner writes specs and gathers feedback until we feel like we have the right approach. Only then do we start writing code. It’s not uncommon to take a couple weeks to think through a feature before building it but once we’ve come up with the right plan, it’s straight into execution mode. The project owner delegates the work, starting with individuals writing up their own issues.
Task Structure
- Company Goals
- Common Roadmap > Quarterly Milestones & Themes
- Projects
Focusing on project-related tasks 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.
- Tasks
Most tasks are part of a project but there's a general backlog too.
Work In Cycles
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.
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.