Linear Step-by-Step: Teams, Cycles, Roadmaps & GitHub

👁 113 reads

Linear is a product management tool built for speed: issues, cycles, projects and roadmaps work from day one, without a week of configuration. This tutorial walks you through the first workspace setup for your team, based on Linear’s official documentation.

Before You Start: Establish Three Rules

Linear works out of the box, but your team needs a few shared rules so the tool doesn’t turn into another list nobody reads. Agree on these before your first cycle:

• who reviews triage and when, for example one person every morning,
• what priorities mean, so “urgent” doesn’t mean everything,
• how you name code branches, so GitHub integration automatically updates statuses.

Write these rules down in one place, ideally in the team description in Linear itself.

Step 1: Workspace and Team

After creating an account, you create your company workspace and first team. A team in Linear is a unit of work, for example a product, mobile app or department. Each team has its own issues, statuses and cycles. For a small company, one team is plenty to start with.

If you’re migrating from another tool, Linear’s documentation describes how to import issues from your existing system.

Step 2: Issues

An issue is the basic unit of work: a bug, task or idea. It has a title, description, assignee, priority and status. Linear is designed around keyboard shortcuts, so you can do almost everything without a mouse: create an issue, change priority, assign someone. You’ll find the full list of shortcuts in the app’s help. Teams report that with shortcuts, you can organize dozens of issues in a few minutes.

Step 3: Cycles - Sprints Without Babysitting

Cycles are repeating work periods, the equivalent of sprints. You set their length, start day and what happens to unfinished tasks. Incomplete issues can roll over to the next cycle automatically, so nobody has to manually move them every two weeks. A good start is two-week cycles with the first cycle filled with issues ready for work.

Step 4: Projects and Roadmap

Projects are for longer initiatives, often spanning multiple teams, like a new app version. A project collects issues, shows progress and lets you publish updates, so your manager doesn’t have to ask in meetings how things are going. Projects combine to form a roadmap visible to the whole company.

Step 5: Triage - Your Inbox

Issues created by integrations or by people outside the team first land in triage. This is an inbox that someone regularly reviews and decides: into the current cycle, onto the backlog, or reject. This keeps the team’s task list from clogging up with issues nobody has reviewed.

Step 6: GitHub Integration

You enable the integration in settings, in the integrations section. Linear links issues to pull requests through branch names, titles or keywords and automatically changes issue status based on what’s happening in the code. You can also sync issues between the repository and team. Practical note: the most reliable linking comes from branch names following Linear’s convention.

Example: First Week for a Five-Person Team

Day one: workspace, one team, import issues from the old spreadsheet. Day two: review issues, set priorities, split into current cycle and backlog. Day three: connect GitHub and establish branch naming convention. From week two, the team stops asking who’s working on what, because it’s visible in the cycle.

In this rollout, day two matters most - the issue review. A team that immediately sets priorities and postpones what’s not urgent starts the first cycle with a realistic plan. A team that dumps everything from the old spreadsheet into the cycle feels defeated after two weeks, even though the only problem was overly optimistic planning.

Common Mistakes

• Too many teams at the start in a small company.
• Unreviewed triage that turns into a junk pile.
• No branch naming convention, so statuses don’t update.

How to Evaluate Your First Cycle

After the first cycle, ask yourselves three questions. How many planned issues did you manage to close, because that’s the first real measure of what fits in two weeks. Was triage reviewed regularly. Did statuses update automatically after merging code, or did someone have to move them manually.

The first cycle is almost always overplanned. That’s normal and exactly why you do it: you plan the second cycle based on data, not optimism.

If your team is coming from another tool, give it two or three cycles to adjust before you judge whether the switch paid off. The first weeks are always slower because people are learning shortcuts and a new work rhythm.

// read moreLinear in Practice: From Startup to Multi-Client AgencyAI ToolsLinear: Product Team Task Management - Plans and PricingAI ToolsRailway Step-by-Step: Deploy from GitHub with DatabaseGuides

Kinetyra