Linear

As my side-projects became more serious endeavors, I wanted to use a project management tool to both as a self-documenting history of the product roadmap, and provide a better overview of the state of the progress and milestones.

I had seen developers mention Linear on Twitter while it was still in beta and saw it supported all of the features I was looking for in a project management tool.

Speed

The first thing I must mention is that the app is fast and has some of the smoothest interactions I’ve seen in both the web app and the Mac app. The developers really went out of their way to get this right. 👏🏽

Github Integration

The integration with Github works in both directions. Issue details are included in the PRs and PR automations automatically move issues to the next step in the workflow.

I use the following workflow in Linear:

And PR automation:

You’ll notice that opening the PR moves it to the In Progress status. I like creating a PR with an empty commit and try to document my thought process as I build out the feature rather than create the PR after the work is completed. I not only have the final implementation, but also a historical record of what didn’t work.

Teams

I’m the only developer on my own apps and work on all the issues, but I still like to split the Issues between different teams e.g. backend, iOS, web, etc. This is reminiscent of the contexts from the GTD system, keeps the focus on the platform I’m working on.

I literally put on different hats when I switch context.

Issues

Linear is essentially built around Issues. Other apps might refer to them as tasks, user stories, etc. I view these as individual units of work, and once again borrowing from GTD, they must be completable and have a definition of done.

Too often, I’ve seen issues like “accessibility” or “look into syncing.” These are vague, with no clear information on how to complete them and will typically live in the backlog forever.

In addition to a title and description, Issues have all the attributes a developer would expect:

• Status: From the workflow above, e.g. In Progress, Done, etc.
• Priority: Urgent, High, Medium, Low or None.
• Estimate: I prefer to use the Fibonacci sequence e.g. 1, 2, 3, 5, 8.
• Labels: I use Bug, Chore, Feature, Improvement.

There are a few attributes (cycle, due date, assignee) that I don’t use. More on that later…

Projects

Every Issue belongs in a Project. I reuse the same concept from GTD again, a project is a just a collection of completable tasks. Any feature that is more than one step is a project.

In fact, the projects in Linear have matching projects in my Bear notes app. I don’t create a project in Linear until I’ve fully thought out how a feature will work, which will then guide the Issues I create.

When a project is completed, I review the comments in the PRs to update the notes in Bear.

Milestones

I use milestones to get a high level view of all the projects in the roadmap across all the teams. As a sports team management app, Lead Dog natively uses the concept of ”seasons,” so my milestones for Lead Dog are also seasons e.g. Spring, Summer, Fall and Winter.

Deck of Pain doesn’t have a similar concept so I simply went with Q1, Q2, Q3 and Q4.

Cycles, Due Dates, Assignees

Linear offers a feature called Cycles which allows you to plan your sprints. I initially enabled it, so I could track progress and also see the velocity and see how many points I complete in a cycle. However, these are my own apps and occasionally I get busy with other things. It is pretty demotivating to see multiple “empty cycles.” For this reason, I disabled cycles for all my projects.

Same for due dates.

I also hide the assignee attribute since it’s always just me, so I don’t need to see it every time.

The only real “time” marker I have are the milestones which usually correlate to some sort of marketing effort.

Looking Ahead

Currently there is no native mobile app. As I mentioned earlier, their web app is insanely fast and performant, but I’d still prefer a native experience.