Linear Schritt für Schritt: Team, Cycles, Roadmap und GitHub

👁 112 Aufrufe

Linear ist ein Tool für Produktentwicklung, das auf Geschwindigkeit ausgelegt ist: Issues, Cycles, Projekte und Roadmaps sind vom ersten Tag an verfügbar, ohne wochenlange Konfiguration. Diese Anleitung führt Sie durch die erste Einrichtung eines Team-Workspace nach der offiziellen Linear-Dokumentation.

Bevor Sie starten: drei Grundregeln festlegen

Linear funktioniert sofort, aber Ihr Team braucht einige gemeinsame Regeln, damit das Tool nicht zu einer weiteren Liste wird, die niemand liest. Legen Sie vor dem ersten Cycle fest:

• wer und wann Triage durchsieht, zum Beispiel eine Person jeden Morgen,
• was Prioritäten bedeuten, damit „dringend“ nicht alles bedeutet,
• wie Sie Branches im Code benennen, damit die GitHub-Integration Status automatisch aktualisiert.

Dokumentieren Sie diese Regeln an einem Ort, am besten in der Team-Beschreibung in Linear selbst.

Schritt 1: Workspace und Team

Nach der Kontoerstellung erstellen Sie einen Workspace für Ihr Unternehmen und das erste Team. Ein Team in Linear ist eine Arbeitseinheit, zum Beispiel ein Produkt, eine mobile App oder eine Abteilung. Jedes Team hat eigene Issues, Status und Cycles. Für kleine Unternehmen reicht anfangs ein Team völlig aus.

Wenn Sie von einem anderen Tool wechseln, beschreibt die Linear-Dokumentation den Import von Issues aus bestehenden Systemen.

Schritt 2: Issues

Ein Issue ist die grundlegende Arbeitseinheit: Bug, Aufgabe, Idee. Es hat einen Titel, Beschreibung, verantwortliche Person, Priorität und Status. Linear ist für Tastaturkürzel optimiert, sodass Sie fast alles ohne Maus erledigen: Issue erstellen, Priorität ändern, Person zuweisen. Die vollständige Liste der Shortcuts finden Sie in der App-Hilfe. Teams berichten, dass sich mit Shortcuts Dutzende Issues in wenigen Minuten organisieren lassen.

Schritt 3: Cycles - Sprints ohne manuelle Verwaltung

Cycles sind wiederholbare Arbeitsperioden, das Äquivalent zu Sprints. Sie legen Länge, Starttag und fest, was mit unerledigten Aufgaben passiert. Unerledigte Issues können automatisch in den nächsten Cycle übertragen werden, sodass niemand sie alle zwei Wochen manuell verschieben muss. Ein guter Start sind zweiwöchige Cycles und der erste Cycle gefüllt mit arbeitsbereiten Issues.

Schritt 4: Projekte und Roadmap

Projekte dienen längeren Vorhaben, oft über mehrere Teams hinweg, zum Beispiel eine neue App-Version. Ein Projekt sammelt Issues, zeigt Fortschritt und ermöglicht Updates, sodass Führungskräfte nicht in Meetings nachfragen müssen, wie es läuft. Aus Projekten setzt sich die für das ganze Unternehmen sichtbare Roadmap zusammen.

Schritt 5: Triage - der Posteingang

Issues, die durch Integrationen oder von Personen außerhalb des Teams erstellt werden, landen zunächst in Triage. Das ist ein Posteingang, den jemand regelmäßig durchsieht und entscheidet: in den aktuellen Cycle, auf die Backlog-Liste oder ablehnen. So wird die Task-Liste des Teams nicht mit ungeprüften Issues überfüllt.

Schritt 6: GitHub-Integration

Die Integration aktivieren Sie in den Einstellungen im Integrations-Bereich. Linear verknüpft Issues mit Pull Requests über Branch-Namen, Titel oder Schlüsselwörter und ändert den Issue-Status automatisch basierend auf Code-Aktivitäten. Sie können auch Issues zwischen Repository und Team synchronisieren. Praxistipp: Die zuverlässigste Verknüpfung erfolgt über Branch-Namen nach Linear-Konvention.

Beispiel: erste Woche eines fünfköpfigen Teams

Tag eins: Workspace, ein Team, Import von Issues aus altem Spreadsheet. Tag zwei: Issue-Review, Prioritäten, Aufteilung in aktuellen Cycle und Backlog. Tag drei: GitHub-Verbindung und Festlegung der Branch-Namenskonvention. Ab der zweiten Woche fragt das Team nicht mehr, wer woran arbeitet, weil es im Cycle sichtbar ist.

Bei dieser Einführung hängt am meisten vom zweiten Tag ab, also vom Issue-Review. Ein Team, das sofort Prioritäten festlegt und nicht Dringendes zurückstellt, startet den ersten Cycle mit einem realistischen Plan. Ein Team, das alles aus dem alten Spreadsheet in den Cycle wirft, hat nach zwei Wochen ein Gefühl des Scheiterns, obwohl das Problem nur zu optimistische Planung war.

Häufigste Fehler

• Zu viele Teams beim Start in kleinen Unternehmen.
• Ungeprüftes Triage, das zur Müllhalde wird.
• Fehlende Branch-Namenskonvention, wodurch sich Status nicht aktualisieren.

Wie Sie den ersten Cycle bewerten

Nach dem ersten Cycle stellen Sie sich drei Fragen. Wie viele geplante Issues konnten geschlossen werden, denn das ist das erste realistische Maß dafür, was in zwei Wochen passt. Wurde Triage laufend durchgesehen. Haben sich Status automatisch nach Code-Merge aktualisiert oder musste jemand sie manuell verschieben.

Der erste Cycle ist fast immer überplant. Das ist normal und genau dafür macht man ihn: Den zweiten Cycle planen Sie bereits auf Basis von Daten, nicht von Optimismus.

Wenn Ihr Team von einem anderen Tool wechselt, geben Sie ihm zwei, drei Cycles zum Eingewöhnen, bevor Sie bewerten, ob sich der Wechsel gelohnt hat. Die ersten Wochen sind immer langsamer, weil Mitarbeiter Shortcuts und den neuen Arbeitsrhythmus lernen.

// weiterlesenRailway Schritt für Schritt: App deployen mit GitHub und DatenbankAnleitungenWie ein Buch mit KI zusammenfassen: Schritt für SchrittAnleitungenWie ein Schreiben an die Behörde verfassen mit KI: Schritt für SchrittAnleitungen

Kinetyra