„In Linear produktiver werden“ heißt selten „schneller tippen“.
Meistens heißt es:
- weniger Klärungsschleifen,
- weniger Meetings,
- weniger halbfertige Tickets,
- und mehr Issues, die sich von Anfang bis Ende umsetzen lassen.
Dieser Workflow übersteht auch einen chaotischen Prozess, denn er verlangt nur, dass du änderst, wie ein einziges Artefakt geschrieben wird.
TL;DR
- Produktivität in Linear ist Klarheit, kein Geschwindigkeitstheater.
- Den größten Hebel hast du bei Issues, die Rückfragen vermeiden: Kontext → Umfang → Akzeptanzkriterien.
- Linears eigene Methode setzt auf Issues statt User Stories und auf kontinuierliche Planung. Diese Ideen passen gut zu echten Teams, wenn du es leichtgewichtig hältst.
- Wenn das Schreiben der Engpass ist, arbeite nicht „mehr Stunden“. Senke die Reibung: Entwirf den Text schnell, dann überarbeite ihn auf Präzision.
1) Jedes Issue beantwortet 3 Fragen (Kontext, Umfang, Fertig)
Wenn jemand dein Issue liest und trotzdem fragt „Was ist das?“ oder „Wann ist es fertig?“, hast du kein Issue geschrieben. Du hast eine Einladung zu einem Meeting geschrieben.
Nutze diese Struktur:
Kontext (warum)
Ein kurzer Absatz:
- Welches Problem lösen wir?
- Wer ist betroffen?
- Was ist der Beleg (Links, Screenshots, Metriken)?
Umfang (was)
Stichpunkte:
- im Umfang
- nicht im Umfang
Fertig (woran wir es erkennen)
Eine Checkliste mit Akzeptanzkriterien.
Auch Linears eigene Anleitung neigt dazu, handlungsfähige Issues statt story-förmiger Artefakte zu schreiben: “Write issues not user stories” (Linear Method).
2) Mit Akzeptanzkriterien Hin und Her vermeiden
Akzeptanzkriterien sind kein „zusätzlicher Papierkram“, wenn sie zwei Tage Unklarheit verhindern.
Halte sie leichtgewichtig:
- für Nutzer sichtbares Verhalten
- Randfälle (2 bis 3 Stichpunkte)
- Performance-Vorgaben (falls relevant)
Die Erklärung von Atlassian ist eine gute Basisreferenz dafür, was Akzeptanzkriterien sind und warum sie wichtig sind (auch wenn du Jira nicht nutzt): Atlassian: Acceptance criteria.
3) „Asynchron umsetzbare“ Tickets schreiben
Hier ist ein schneller Test:
Könnte ein Teammitglied in einer anderen Zeitzone dieses Ticket morgen übernehmen und ausliefern, ohne dich anzurufen?
Wenn nicht, ergänze:
- Links zu Designs/Logs
- erwartetes vs. tatsächliches Verhalten (bei Bugs)
- eine kurze Liste mit „Nicht-Zielen“
4) Linear wie einen Editor nutzen, nicht wie ein Formular
Linears Editor ist zum Schreiben gebaut und nicht zum Ausfüllen von Formularen. Deshalb ist die obige Struktur günstig anzuwenden. Zwei Referenzen:
Wenn du in der App schneller werden willst, lohnt es sich außerdem, die Shortcut-Hilfe zu lernen (oder wenigstens zu überfliegen):
Es geht nicht darum, jeden Shortcut auswendig zu lernen. Es geht darum, die winzigen UI-Interaktionen loszuwerden, die du die ganze Woche wiederholst.
5) Eine wiederverwendbare Vorlage nutzen
Kopiere diese Vorlage in deine Issues:
Vorlage: Feature / Verbesserung
- Kontext: …
- Ziel: …
- Nicht-Ziele: …
- Ansatz (optional): …
- Akzeptanzkriterien:
- [ ] …
- [ ] …
- [ ] …
- Links: Designs, Doku, PRs
Vorlage: Bug
- Zusammenfassung: …
- Schritte zur Reproduktion:
- …
- …
- Erwartet vs. tatsächlich: …
- Auswirkung / Schweregrad: …
- Akzeptanzkriterien:
- [ ] Regressionstest hinzugefügt
- [ ] Fix verifiziert auf …
- Links: Logs, Screenshots
6) Wenn das Schreiben dein Engpass ist: schnell entwerfen, dann überarbeiten
Ein Issue zu schreiben dauert so lange, dass Leute es verkürzen, und das verkürzte Issue ist das, was später ein Meeting kostet.
Ein praktischer Ausweg:
- Schnell entwerfen (nicht mitten im Satz selbst redigieren)
- Dann die 10 % überarbeiten, auf die es ankommt (Namen, IDs, Links, Formatierung)
Eine Möglichkeit, die Reibung unter macOS zu senken, ist Sprache-zu-Text für den ersten Entwurf (besonders für Kontext und Akzeptanzkriterien) und die Tastatur für präzise Korrekturen.
Wenn du die genaue Einrichtung für Linear willst: /how-to/linear-mac-dictation
7) „Vibe Coding“ macht Tickets wichtiger, nicht unwichtiger
Wenn dein Team KI-first-Editoren oder „Vibe-Coding“-Workflows nutzt, verschiebt sich der Engpass:
- weniger Zeit, Code von Grund auf zu tippen
- mehr Zeit, festzulegen, was passieren soll
- mehr Bedarf an einer Review-Checkliste
Das macht klare Issues und Akzeptanzkriterien noch wertvoller.
Anleitung: /blog/vibe-coding
Weiterlesen
- Linear einrichten (Mac): /how-to/linear-mac-dictation
- GitHub Issues (Mac): /how-to/github-issues-mac-dictation
- Jira (Mac): /how-to/jira-mac-dictation
- Remote-Arbeit: /solutions/remote-work
Quellen
- Linear Method: Write issues not user stories
- Linear Docs: Create issues
- Linear Docs: Editor
- Linear: Keyboard shortcuts help
- Überblick zu Akzeptanzkriterien: Atlassian
- Vortrag zu Produkt und Prozess: Karri Saarinen (CEO of Linear) on product management practices (YouTube)
