Diese Haltung erklärt, warum Linear in Gesprächen mit Entwicklungsteams selten neutral bewertet wird. Wer aus einem stark konfigurierten System kommt, in dem jedes Feld, jeder Statusübergang und jede Berechtigung individuell festgelegt wurde, empfindet Linear zunächst als Einschränkung. Wer dagegen jahrelang an der Trägheit und dem Konfigurationsballast solcher Systeme gelitten hat, erlebt Linear als Befreiung. Beide Reaktionen sind berechtigt und beschreiben denselben Sachverhalt aus unterschiedlichen Blickwinkeln: Linear tauscht Flexibilität gegen Tempo.
Für die Einordnung in dieser Wissensdatenbank ist wichtig, dass Linear kein allgemeines Projektmanagement-System ist. Es kennt keine Ressourcenplanung, keine Netzplantechnik, keine Budgetverfolgung und keine klassische Zeiterfassung. Es ist ein Fachwerkzeug für die Frage, welche Arbeit ein Produkt- oder Entwicklungsteam in den nächsten Tagen und Wochen erledigt und wie weit sie gediehen ist. Diese Fokussierung ist die eigentliche Produktentscheidung — und der Grund, weshalb die Auswahlfrage fast immer lautet, ob das eigene Team in diese Fokussierung hineinpasst.
In den meisten Werkzeugen dieser Kategorie ist Konfigurierbarkeit das Verkaufsargument. Linear dreht das um. Die Zahl der Felder je Issue ist bewusst klein gehalten, die Statusmodelle folgen einem festen Grundraster, und viele Entscheidungen, die andere Systeme dem Administrator überlassen, hat der Anbieter bereits getroffen. Der Effekt ist paradox und in der Praxis gut zu beobachten: Weil weniger einstellbar ist, wird weniger diskutiert. Teams verbringen keine Wochen damit, ein Berechtigungsschema oder eine Feldstruktur zu entwerfen, sondern beginnen zu arbeiten.
Der zweite Baustein ist Geschwindigkeit als Produkteigenschaft. Die Anwendung ist so gebaut, dass Änderungen unmittelbar sichtbar sind und Ansichtswechsel keine Wartezeit erzeugen. Technisch steckt dahinter unter anderem eine lokale Datenhaltung im Client, die Bedienschritte sofort quittiert und die Synchronisierung im Hintergrund erledigt. Dieser Unterschied klingt nach einem Detail, verändert aber das Nutzungsverhalten deutlich spürbar: Wenn das Aktualisieren eines Status eine Sekunde statt fünf kostet, wird es tatsächlich getan. Datenqualität in Tracking-Systemen ist zu einem erheblichen Teil eine Frage der Bedienreibung.
Der dritte Baustein ist die durchgängige Tastaturbedienung. Praktisch jede Handlung lässt sich über Kürzel oder eine Befehlspalette auslösen, ohne die Maus zu berühren. Für Menschen, die den ganzen Tag in einer Entwicklungsumgebung arbeiten und Tastaturbedienung gewohnt sind, ist das ein erheblicher Komfortgewinn. Für Kolleginnen und Kollegen aus nicht-technischen Bereichen ist es zunächst eine Hürde, weil die Oberfläche wenig sichtbare Schaltflächen anbietet und ihre Möglichkeiten nicht anbiedernd zeigt. Diese Zielgruppenschärfe ist kein Zufall, sondern gewollt.
Die Kernzielgruppe sind Produkt- und Entwicklungsteams in einer Größe, in der Abstimmung noch direkt möglich ist: von wenigen Personen bis in den mittleren zweistelligen Bereich, häufig verteilt auf mehrere Teams innerhalb eines Arbeitsbereichs. Typisch sind Softwarehäuser, Produktbereiche in etablierten Unternehmen, interne Entwicklungsabteilungen und Agenturen mit eigenem Entwicklungsanteil. Gemeinsam ist diesen Konstellationen, dass Arbeit in überschaubaren Iterationen fließt und die Beteiligten technische Werkzeuge gewohnt sind.
Weniger passend ist Linear dort, wo ein Werkzeug möglichst viele Fachbereiche gleichzeitig bedienen soll. Wenn Vertrieb, Personal, Buchhaltung und Produktion dieselbe Plattform nutzen sollen, ist die Fokussierung von Linear ein Nachteil, weil genau die Felder, Formulare und Auswertungen fehlen, die diese Bereiche brauchen. Das ist kein Mangel des Produkts, sondern das Ergebnis seiner Positionierung. Wer diese Grenze vorab akzeptiert, trifft eine tragfähige Entscheidung; wer sie überdehnt, landet nach einigen Monaten bei Tabellen neben dem Werkzeug.
Linear gehört in diese Kategorie, weil es die geteilte Sicht auf laufende Arbeit organisiert und damit einen erheblichen Teil der Abstimmung ersetzt, die sonst in Chats, Statusmeetings und Zurufen stattfindet. Der Wertbeitrag liegt weniger in der Verwaltung einzelner Aufgaben als in der gemeinsamen Priorisierung: Ein Team, das in einer Ansicht sieht, was im aktuellen Zyklus zugesagt ist, was zurückgestellt wurde und was unerwartet hereinkam, diskutiert anders als ein Team, das diese Information erst zusammensuchen muss.
Zugleich ist die Abgrenzung nach oben und unten hilfreich. Nach unten grenzt sich Linear von einfachen Aufgabenlisten und Kanban-Werkzeugen ab, weil es Entwicklungsspezifika mitbringt — Verknüpfung mit Quellcode-Verwaltung, Zyklen, Triage-Prozesse, technische Beziehungen zwischen Issues. Nach oben grenzt es sich von Portfolio- und Programmwerkzeugen ab, weil es keine Kapazitätsrechnung über Abteilungen hinweg, keine Kostenverfolgung und keine Mehrprojekt-Ressourcensteuerung leistet. Diese doppelte Abgrenzung ist die praktische Auswahlhilfe.
Die kostenfreie Stufe ist bei Linear kein reines Schaufenster. Ein kleines Team kann damit Issues anlegen, priorisieren, in Zyklen einplanen und über die üblichen Ansichten steuern. Begrenzt sind typischerweise die Menge aktiv verwalteter Issues, die Tiefe der Auswertungen, der Umfang der Automatisierung, die Zahl paralleler Teams innerhalb des Arbeitsbereichs sowie Verwaltungs- und Sicherheitsfunktionen. Für einen Piloten, eine kleine Produktinitiative oder eine Bewertungsphase ist das in der Regel ausreichend.
Wie bei allen produktgetriebenen Werkzeugen gilt jedoch der Governance-Hinweis: Weil der Einstieg ohne Beschaffungsvorgang funktioniert, entstehen Arbeitsbereiche häufig an der IT vorbei. In der Praxis findet man Linear nicht selten bereits im Haus, wenn die Frage nach einer offiziellen Einführung erstmals gestellt wird — eingeführt von einem Entwicklungsteam, das die Reibung des Bestandssystems nicht länger tragen wollte. Diese Vorgeschichte ist bei der Bewertung ehrlich einzubeziehen, weil sie sowohl über den tatsächlichen Nutzen als auch über bestehende Datenschutzlücken Auskunft gibt.
Die erste kostenpflichtige Stufe adressiert Teams, die über die Limits der kostenfreien Nutzung hinauswachsen. Sie hebt typischerweise Mengenbegrenzungen auf, öffnet weitere Integrationen und erlaubt eine breitere Nutzung von Zyklen, Ansichten und Importen. Der Charakter der Nutzung ändert sich dabei kaum — man arbeitet wie vorher, nur ohne an Grenzen zu stoßen. Für ein einzelnes Entwicklungsteam ist das häufig schon die dauerhaft passende Stufe.
Die zweite kostenpflichtige Stufe markiert den qualitativen Sprung. Hier kommen üblicherweise die Funktionen hinzu, die aus einem Team-Werkzeug ein Planungswerkzeug für mehrere Teams machen: erweiterte Roadmap- und Initiativen-Funktionen, tiefere Auswertungen zu Durchsatz und Vorhersagbarkeit, umfangreichere Automatisierung und Regeln, erweiterte Verwaltung von Teams und Rollen sowie Anbindungen an Support- und Kundenprozesse. Für Organisationen, die mehrere Produktteams parallel führen und gegenüber einer Leitung berichten müssen, ist meist erst diese Stufe wirklich tragfähig.
Die Enterprise-Stufe richtet sich an Organisationen mit formalisierten Anforderungen an Informationssicherheit, Identitätsverwaltung und Nachvollziehbarkeit. Typische Inhalte sind erweiterte Single-Sign-on- und Verzeichnisanbindung inklusive automatisierter Benutzerbereitstellung, feinere Rechte- und Sichtbarkeitssteuerung, erweiterte Protokollierung, vertragliche und organisatorische Zusagen sowie ein gehobenes Support- und Betreuungsniveau. Für die einzelne Anwenderin ändert sich wenig; für IT, Datenschutz und Revision ändert sich viel.
Für den Mittelstand lautet die nüchterne Einordnung: Diese Stufe rechnet sich meist erst, wenn Linear zum verbindlichen Standard mehrerer Teams erklärt wurde und Anforderungen aus Zertifizierungen, Kundenverträgen oder Konzernvorgaben bestehen. Kleinere Organisationen kommen häufig weiter, wenn sie den Einsatz bewusst auf klar benannte Teams begrenzen, die Governance dort sauber halten und den Rest der Organisation nicht mit hineinziehen. Eine unternehmensweite Verwaltungsschicht für einen fachlich engen Anwendungsfall zu bezahlen, ist selten wirtschaftlich.
Ein Issue ist die kleinste eigenständige Arbeitseinheit. Es trägt einen Titel, eine Beschreibung, einen Status, eine Priorität, optional eine Schätzung, Zuordnungen zu Person, Team, Projekt und Zyklus sowie Labels. Beziehungen zu anderen Issues sind vorgesehen — als Unteraufgabe, als Duplikat, als blockierende oder blockierte Abhängigkeit, als inhaltliche Verknüpfung. Diese Beziehungen sind für Entwicklungsarbeit ausreichend, aber ausdrücklich keine Netzplantechnik: Sie dokumentieren Zusammenhänge, verschieben aber keine Termine automatisch entlang einer Kette.
Das Statusmodell folgt einem festen Grundraster mit den Kategorien Rückstand, geplant beziehungsweise nicht begonnen, in Arbeit, abgeschlossen und abgebrochen. Innerhalb dieser Kategorien lassen sich eigene Status anlegen, sodass ein Team etwa zwischen Umsetzung, Codeprüfung und Abnahme unterscheiden kann. Der Zwang zur Einordnung in eine der Oberkategorien ist eine der wichtigsten Entwurfsentscheidungen des Produkts: Sie macht teamübergreifende Auswertungen überhaupt erst möglich, weil jedes Issue trotz unterschiedlicher Detailstatus vergleichbar bleibt.
Die Anlage von Issues ist bewusst auf Geschwindigkeit getrimmt. Über eine Befehlspalette und Tastenkürzel entsteht ein Issue in wenigen Sekunden, samt Zuweisung und Priorität, ohne dass ein Formular durchlaufen werden muss. Ergänzend gibt es Vorlagen für wiederkehrende Arbeitstypen — etwa Fehlerberichte mit vorgegebener Gliederung — und die Möglichkeit, Issues aus anderen Systemen heraus zu erzeugen, etwa aus einem Chat, einem Support-Ticket oder einer Fehlerüberwachung. In der Praxis ist diese niedrige Anlageschwelle der Hauptgrund dafür, dass in Linear tendenziell mehr und kleinteiliger dokumentiert wird als in schwergängigen Systemen.
Cycles sind Zeitfenster fester Länge, in die Arbeit eingeplant wird — konzeptionell verwandt mit Sprints, aber schlanker gedacht. Ein Zyklus startet und endet automatisch nach dem eingestellten Rhythmus, nicht erledigte Arbeit wandert je nach Konfiguration in den nächsten Zyklus, und die Auswertung zeigt, wie viel zugesagt und wie viel tatsächlich abgeschlossen wurde. Der entscheidende Unterschied zu klassischen Sprint-Implementierungen ist die Automatik: Es gibt keine aufwendige Planungs- und Abschlussmechanik, der Zyklus läuft weiter, ob das Team ihn feierlich abschließt oder nicht.
Projects bündeln Arbeit dagegen nicht nach Zeit, sondern nach Vorhaben. Ein Projekt hat ein Ziel, einen Verantwortlichen, einen Status, optional einen Zeitraum, eine Beschreibung und regelmäßige Fortschrittsaktualisierungen. Es kann Issues aus mehreren Teams enthalten — das ist der Mechanismus, mit dem teamübergreifende Vorhaben in Linear abgebildet werden. Die Kombination ist wichtig zu verstehen: Ein Issue kann gleichzeitig einem Zyklus und einem Projekt angehören. Der Zyklus antwortet auf die Frage, wann gearbeitet wird, das Projekt auf die Frage, woran.
Triage ist der Eingangsbereich für Arbeit, die von außen kommt: gemeldete Fehler, Kundenanliegen, Anfragen aus anderen Abteilungen, automatisch erzeugte Meldungen aus Überwachungssystemen. Statt solche Eingänge direkt in den Rückstand zu schütten, landen sie in einer Warteschlange, in der eine verantwortliche Person sie annimmt, ablehnt, als Duplikat markiert oder weiterleitet. Dieser eine Mechanismus ist aus Beratungssicht einer der unterschätzten Vorteile von Linear, weil er das häufigste Qualitätsproblem in Tracking-Systemen adressiert: einen Rückstand, in dem niemand mehr zwischen echter Arbeit und ungeprüften Meldungen unterscheiden kann.
Oberhalb der Projekte stehen Initiativen beziehungsweise Roadmap-Strukturen, die mehrere Projekte zu einem strategischen Vorhaben zusammenfassen und über einen Zeitraum darstellen. Diese Ebene ist für die Kommunikation mit der Leitung gedacht: Sie zeigt, welche größeren Vorhaben laufen, wie weit sie fortgeschritten sind und welche Projekte dazugehören. Die Darstellung bleibt bewusst grob — es geht um Quartalslogik und Zielbilder, nicht um Wochenpläne. Wer eine belastbare Terminplanung mit Abhängigkeiten und kritischem Pfad erwartet, wird auf dieser Ebene enttäuscht, und zwar bewusst.
Views sind gespeicherte Ansichten, die aus Filtern, Gruppierungen und Sortierungen bestehen und als Liste oder Board dargestellt werden. Praktisch jede Rolle baut sich daraus ihren eigenen Arbeitsplatz: die Entwicklerin eine Ansicht ihrer eigenen offenen Issues nach Priorität, die Teamleitung eine Ansicht aller blockierten Issues über alle Teams, das Produktmanagement eine Ansicht aller Issues eines Kundenprojekts unabhängig vom Zyklus. Weil diese Ansichten geteilt werden können, entsteht daraus eine leichtgewichtige Form von Berichtswesen ohne separates Auswertungswerkzeug.
Insights beziehungsweise die eingebauten Auswertungen liefern Kennzahlen zu Durchsatz, Verteilung, Alterung und Zyklusverlauf — etwa wie viele Issues je Zeitraum abgeschlossen wurden, wie lange Arbeit im Durchschnitt in Bearbeitung ist oder wie sich der Rückstand entwickelt. Diese Auswertungen sind für die Selbststeuerung eines Teams gut geeignet und für ein Führungscockpit über viele Bereiche hinweg zu schmal. Der Umfang ist edition- und stichtagsabhängig und beim Anbieter zu prüfen. Wer tiefere Analysen braucht, exportiert über die Schnittstelle in ein Auswertungswerkzeug.
Die Tastaturbedienung verdient einen eigenen Abschnitt, weil sie kein Zusatzfeature ist, sondern das primäre Bedienkonzept. Eine Befehlspalette nimmt praktisch jede Handlung als Texteingabe an, Kürzel führen direkt zu Ansichten, Zuweisungen, Statuswechseln, Prioritäten und Suchen. Wer diese Kürzel beherrscht, arbeitet deutlich schneller als mit der Maus — und genau darauf ist die Oberfläche optimiert. Der Nebeneffekt: Die Anwendung wirkt für Ungeübte karg, weil sie ihre Fähigkeiten nicht in Schaltflächen ausbreitet, sondern hinter Eingaben verbirgt.
Für die Einführung folgt daraus eine konkrete Empfehlung: Die erste Schulung sollte nicht Funktionen erklären, sondern zehn Tastenkürzel. Teams, die diese Kürzel früh lernen, erleben den Geschwindigkeitsvorteil unmittelbar und pflegen ihre Issues entsprechend zuverlässig. Teams, die Linear mit der Maus bedienen, erleben ein normales Werkzeug mit ungewohnt wenigen Feldern und fragen nach einigen Wochen, worin der Vorteil bestand. Der Unterschied liegt nicht im Produkt, sondern in der Einweisung.
Der wichtigste Automatisierungseffekt entsteht aus Konventionen, die das Produkt selbst durchsetzt. Zyklen beginnen und enden ohne manuelles Zutun, unerledigte Arbeit wird nach eingestellter Regel übernommen, Issues wechseln ihren Status automatisch, wenn im verbundenen Quellcode-System ein Änderungsantrag geöffnet, geprüft oder zusammengeführt wird, und abgeschlossene Arbeit verschwindet nach definierter Zeit aus der aktiven Ansicht. Diese Automatik ersetzt in der Praxis einen großen Teil der Regeln, die Teams in anderen Systemen von Hand bauen — und sie ist verlässlicher, weil sie nicht von der Pflege einer Regelsammlung abhängt.
Ergänzend gibt es regelbasierte Automatisierungen für die verbleibenden Fälle: Zuweisungen anhand von Labels oder Bereichen, automatisches Setzen von Prioritäten für bestimmte Eingangskanäle, Benachrichtigungen an definierte Kanäle bei Statuswechseln, Weiterleitung von Triage-Eingängen an das zuständige Team, Erinnerungen an Fortschrittsaktualisierungen für Projekte. Der Zuschnitt dieser Regeln unterscheidet sich von Edition zu Edition und entwickelt sich weiter; verbindlich ist die Anbieterdokumentation.
KI-gestützte Funktionen zielen in Werkzeugen dieser Art auf drei wiederkehrende Aufgaben, und Linear ist darin keine Ausnahme. Erstens die Vorsortierung im Triage: Ein eingehendes Anliegen wird automatisch einem Team oder Themenbereich zugeordnet, mit Labels versehen, auf mögliche Duplikate geprüft und mit ähnlichen bestehenden Issues verknüpft. Das entlastet genau die Rolle, die in wachsenden Organisationen zum Engpass wird — die Person, die den Eingang sichtet.
Zweitens die Zusammenfassung: aus einer langen Diskussion in einem Issue der Stand in wenigen Sätzen, aus einem Projekt mit vielen Issues ein Fortschrittsbericht, aus einem abgeschlossenen Zyklus ein Rückblick. Diese Funktionen sind hilfreich, wenn Informationen für Menschen aufbereitet werden müssen, die nicht täglich im Werkzeug arbeiten. Drittens die Formulierungshilfe: aus einer stichwortartigen Notiz eine verständliche Aufgabenbeschreibung, aus einem groben Vorhaben eine Liste konkreter Teilaufgaben.
Die nüchterne Bewertung aus Beratungssicht: KI-Funktionen sind in einem Issue-Tracker ein Komfort- und Entlastungsgewinn, kein Strukturgewinn. Sie beschleunigen Arbeit, die ohnehin getan werden müsste, und sie können ein schlecht geführtes System nicht retten. Wo Prioritäten unklar sind, wo niemand für den Eingang verantwortlich ist und wo Teams ihre Zuständigkeiten nicht geklärt haben, produziert KI-Unterstützung schneller mehr von demselben Durcheinander. Verfügbarkeit, Editionsbindung und Funktionsumfang dieser Funktionen sind vor einer Entscheidung beim Anbieter zu prüfen.
Eine neuere Entwicklung, die für Entwicklungsteams besonders relevant ist, betrifft die Anbindung von KI-Agenten an das Tracking-System. Die Idee: Ein Agent erhält Zugriff auf Issues, liest Beschreibung und Kontext, arbeitet an einer Umsetzung, hinterlegt Ergebnisse und aktualisiert den Status. Technisch geschieht das über die Programmierschnittstelle des Werkzeugs oder über standardisierte Protokolle für Werkzeugzugriff durch Sprachmodelle, die unter dem Begriff Model Context Protocol bekannt geworden sind. Ob und in welcher Form Linear solche Anbindungen offiziell unterstützt, entwickelt sich derzeit schnell und ist beim Anbieter zu prüfen.
Unabhängig vom jeweiligen Stand gilt die Grundregel: Eine offene, gut dokumentierte Schnittstelle ist die eigentliche Automatisierungsgrundlage. Linear stellt eine Programmierschnittstelle mit Abfragesprache sowie Ereignisbenachrichtigungen bereit, mit denen Teams eigene Verknüpfungen bauen — Issues aus einem Fachsystem erzeugen, Kennzahlen in ein Berichtswerkzeug exportieren, Freigabeprozesse anstoßen, Meldungen aus dem Betrieb einsteuern. Wer Automatisierung ernst nimmt, prüft diese Schnittstelle genauer als jede Liste vorgefertigter Regeln.
Zugleich verdient dieser Bereich eine Governance-Betrachtung, die in der Begeisterung oft ausgelassen wird. Jeder Agent und jede Schnittstellenanbindung ist ein Zugang zu Unternehmensdaten mit eigenen Rechten. Zu klären sind: Wer darf Zugangsschlüssel erzeugen, wie werden sie verwahrt und rotiert, welche Rechte erhält ein Agent tatsächlich, werden seine Handlungen protokolliert und im Issue-Verlauf als maschinell erzeugt erkennbar, und welche Inhalte dürfen an einen externen Modellanbieter übertragen werden. Diese Fragen gehören vor die erste Anbindung, nicht danach.
Die wichtigste Integration ist die zu GitHub und GitLab. Sie funktioniert in beide Richtungen: Ein Branch oder ein Änderungsantrag wird über eine Kennung mit dem Issue verknüpft, der Status des Issues folgt dem Fortschritt der Codeprüfung, und beim Zusammenführen schließt sich das Issue automatisch. Umgekehrt lassen sich aus einem Issue heraus Branch-Namen erzeugen, die die Verknüpfung von Anfang an herstellen. Der Effekt auf die Datenqualität ist erheblich, weil Statuspflege nicht mehr als separate Tätigkeit anfällt, sondern als Nebenprodukt der Entwicklungsarbeit entsteht.
Diese Kopplung ist gleichzeitig ein Auswahlkriterium. Teams, die ihre Quellcode-Verwaltung in einem der gängigen Systeme betreiben, profitieren unmittelbar. Teams mit exotischeren oder selbst betriebenen Umgebungen sollten vorab prüfen, welche Verbindungsvarianten unterstützt werden — insbesondere bei selbst gehosteten Installationen, bei denen Netzwerkfreigaben und Authentifizierung zu klären sind. Die Prüfung sollte konkret mit der eigenen Umgebung erfolgen, nicht anhand einer Funktionsliste.
Die Anbindung an Slack ist in vielen Teams der zweite Pfeiler. Sie erlaubt, aus einer Nachricht heraus ein Issue zu erzeugen, Statusänderungen in Kanäle zu spiegeln, Kommentare zwischen beiden Systemen zu synchronisieren und Triage-Eingänge dort zu bearbeiten, wo die Diskussion ohnehin läuft. Das ist mehr als Bequemlichkeit: Es adressiert das häufigste Leck in der Arbeitsverfolgung, nämlich Arbeit, die im Chat besprochen und nie erfasst wird. Für Organisationen, die auf Microsoft Teams setzen, ist der jeweils aktuelle Integrationsstand gesondert zu prüfen, da die Tiefe hier historisch geringer ausfiel.
Für Produktteams ist die Verbindung zu Figma relevant, weil Entwürfe direkt in Issues eingebettet und mit Vorschau dargestellt werden — Diskussionen über Umsetzungen laufen damit am Entwurf statt an Beschreibungen. Auf der Betriebsseite stehen Anbindungen an Fehlerüberwachung wie Sentry bereit: Eine gehäuft auftretende Ausnahme erzeugt automatisch ein Issue oder wird einem bestehenden zugeordnet, samt technischem Kontext. Damit landet Betriebsrealität im gleichen Rückstand wie geplante Arbeit, was Priorisierungsdiskussionen erheblich versachlicht.
Auf der Kundenseite sind Verbindungen zu Support-Systemen wie Zendesk und Intercom von Bedeutung. Sie erlauben, aus einem Kundenanliegen ein Issue zu erzeugen, mehrere Anliegen an dasselbe Issue zu hängen und den Support automatisch zu informieren, wenn das Issue geschlossen wird. Dieser Rückkanal ist der Punkt, an dem Produktarbeit und Kundenerfahrung methodisch verbunden werden: Statt einer gefühlten Priorität entsteht eine belegte, weil sichtbar ist, wie viele Kundenanliegen an einem Issue hängen.
Jenseits der vorgefertigten Verbindungen ist die Programmierschnittstelle die eigentliche Erweiterungsebene. Linear stellt eine Schnittstelle mit Abfragesprache bereit, über die Issues, Projekte, Zyklen, Kommentare und Metadaten gelesen und geschrieben werden können, ergänzt um Ereignisbenachrichtigungen, die Zielsysteme über Änderungen informieren. Damit lassen sich Verknüpfungen zu Fachanwendungen, Berichtswerkzeugen, Datenspeichern oder Freigabeprozessen bauen. Für die Bewertung im Mittelstand ist das ein wichtiger Punkt, weil es die Abhängigkeit von einem Marktplatz vorgefertigter Erweiterungen reduziert.
Auf der Verwaltungsseite stehen Single Sign-on über die gängigen Standards und, abhängig von der Edition, automatisierte Benutzerbereitstellung über ein Verzeichnis bereit. Beides ist für eine offizielle Einführung praktisch unverzichtbar: Ohne zentrale Anmeldung entstehen lokale Kennwörter außerhalb der Kontrolle der IT, und ohne automatisierte Bereitstellung bleiben ausgeschiedene Mitarbeitende im System. Welche Varianten in welcher Edition verfügbar sind, ändert sich und ist beim Anbieter zu prüfen.
Ein bewusst genannter blinder Fleck: Linear bietet kein Self-Hosting. Es gibt keine Variante zum Betrieb im eigenen Rechenzentrum und keine Option, den Datenbestand auf eigener Infrastruktur zu halten. Für Organisationen mit entsprechender Anforderung ist das ein Ausschlusskriterium, das keine Integrationstiefe kompensiert. Wir behandeln diesen Punkt im Kapitel zu Kosten und Datenhoheit ausführlich, weil er in der Praxis häufiger entscheidet als jede Funktionsdiskussion.
Jira ist der Bezugspunkt, gegen den Linear positioniert wird. Der Unterschied ist strukturell: Jira ist ein konfigurierbares System, das nahezu jeden Prozess abbilden kann — mit Vorgangstypen, erzwungenen Statusübergängen, Berechtigungsschemata, Bildschirmmasken, umfangreicher Auswertung und einem großen Marktplatz für Erweiterungen. Diese Mächtigkeit hat einen Preis in Einrichtungsaufwand, Bedienreibung und der Notwendigkeit einer administrierenden Rolle. Linear verzichtet auf diese Mächtigkeit und gewinnt Tempo. Die Entscheidungsfrage lautet daher: Braucht die Organisation erzwungene Prozesse, Auditnachweise, Anbindung an IT-Service-Management und teamübergreifende Portfoliologik, oder braucht sie ein schnelles Werkzeug für ein Entwicklungsteam?
Azure DevOps ist die naheliegende Wahl für Organisationen, die tief in der Microsoft-Welt arbeiten und Arbeitsverfolgung, Quellcode-Verwaltung, Build-Automatisierung, Artefaktverwaltung und Testmanagement in einer Umgebung mit einer Lizenz haben wollen. Diese Bündelung ist ein starkes Argument, insbesondere wenn Verzeichnis und Identitätsverwaltung ohnehin dort liegen. Die Arbeitsverfolgung wirkt im direkten Vergleich schwergängiger, dafür ist die Prozesskette vollständig. Shortcut liegt konzeptionell am nächsten bei Linear — schlankes Tracking für Softwareteams mit Iterationen und Roadmap-Ebene — und ist damit die ernsthafteste Alternative, wenn der Entscheidungsrahmen bereits auf leichtgewichtige Werkzeuge eingegrenzt ist.
GitHub Projects ist die pragmatischste Alternative für Teams, die vollständig auf GitHub arbeiten und keinen weiteren Anbieter einführen wollen. Aufgaben liegen unmittelbar neben dem Code, es entstehen keine zusätzlichen Verträge und keine zusätzliche Anmeldung. Die Grenzen zeigen sich, sobald Planung über einzelne Vorhaben hinaus nötig wird: Zyklusmechanik, Triage-Prozesse, Auswertungen und Roadmap-Ebene sind deutlich schwächer ausgeprägt. Für kleine Teams mit engem Fokus reicht das häufig; für ein Produktteam, das Priorisierung und Vorhersagbarkeit steuern muss, meist nicht.
Asana und ClickUp spielen in einer anderen Liga desselben Marktes: breite Arbeitsmanagement-Plattformen für viele Fachbereiche, mit Abhängigkeiten, Auslastungssichten, Formularen, Zielen und umfangreichem Berichtswesen. Sie sind die richtige Wahl, wenn ein Werkzeug Marketing, Vertrieb, Personal und Projektarbeit gleichzeitig bedienen soll. Für reine Entwicklungsarbeit sind sie im Vergleich zu Linear umständlicher, weil ihnen die Entwicklungsspezifika fehlen — Codeverknüpfung, Zyklusautomatik, technische Beziehungen zwischen Arbeitseinheiten.
Notion schließlich ist keine direkte Alternative, sondern eine Ergänzung, die gelegentlich als Alternative eingesetzt wird. Seine Stärke liegt in der Verzahnung von Dokumentation, Wissen und Aufgaben in einem Raum. Wer Anforderungsdokumente, Entscheidungsprotokolle und Aufgaben nebeneinander führen will, ist dort gut aufgestellt. Als Tracking-System für laufende Entwicklungsarbeit fehlen jedoch Geschwindigkeit, Zyklusmechanik und Codeanbindung. Die in der Praxis häufig anzutreffende Kombination lautet: Dokumentation in Notion oder Confluence, Umsetzung in Linear.
Aus Beratungssicht führen drei Fragen zuverlässiger zu einer guten Entscheidung als jede Funktionsmatrix. Erstens: Wer arbeitet täglich darin? Sind es überwiegend technische Rollen, spricht viel für Linear; sitzen nicht-technische Fachbereiche mit am Tisch, spricht viel für eine breitere Plattform. Zweitens: Welche Nachweise werden gebraucht? Wo Prozessdurchsetzung, Freigabedokumentation oder revisionssichere Nachvollziehbarkeit gefordert sind, sind konfigurierbare Systeme im Vorteil. Drittens: Welche Datenhoheitsanforderung gilt? Wo Self-Hosting oder garantierter EU-Betrieb verlangt wird, scheidet ein reiner Cloud-Anbieter ohne solche Option unabhängig von allen Funktionen aus.
Bemerkenswert ist außerdem, wie häufig die richtige Antwort Koexistenz lautet. Organisationen führen Entwicklungsarbeit in Linear und Service- oder Verwaltungsprozesse in einem anderen System, dokumentieren in einer Wissensplattform und kommunizieren in einem Chat. Diese Arbeitsteilung ist kein Versäumnis, solange eine klare Regel existiert, welche Art von Arbeit wo geführt wird. Problematisch wird es erst, wenn dieselbe Arbeit in zwei Systemen gepflegt wird — dann entsteht doppelter Aufwand und einfache Unklarheit darüber, welche Quelle gilt.
Die tragende Strukturentscheidung ist der Teamschnitt. In Linear ist ein Team keine Verwaltungseinheit, sondern der Container für Issues, Zyklen, Status und Triage-Eingang. Der Schnitt bestimmt damit, welche Arbeit gemeinsam geplant und gemeinsam gemessen wird. Zwei Fehler sind verbreitet: zu feine Teams, die für jede Komponente ein eigenes Gebilde anlegen und damit Zyklusplanung und Auswertung zersplittern; und zu grobe Teams, in denen zwanzig Personen an unverbundenen Themen arbeiten und der gemeinsame Zyklus keine Bedeutung mehr hat. Bewährt hat sich die Orientierung an tatsächlichen Planungseinheiten: Menschen, die zusammen priorisieren, gehören in ein Team.
Ergänzend braucht jede Einheit benannte Verantwortlichkeiten. Wer verantwortet den Triage-Eingang, und in welchem Rhythmus wird er gesichtet? Wer entscheidet über Prioritäten, wenn Kundenanliegen und geplante Arbeit konkurrieren? Wer pflegt Projekte und schreibt Fortschrittsaktualisierungen? Diese Rollen müssen nicht formell sein, aber sie müssen besetzt sein. Ein Triage-Eingang ohne Verantwortliche verwandelt sich innerhalb weniger Wochen in eine zweite unsortierte Halde neben dem Rückstand — und damit ist der wichtigste Vorteil des Konzepts verspielt.
Die häufigste Ausgangslage ist der Wechsel von Jira. Linear bietet Importwerkzeuge für gängige Quellsysteme, die Issues samt Titel, Beschreibung, Status, Zuweisung und Kommentaren übernehmen. Technisch ist das der einfachere Teil. Die eigentliche Arbeit besteht in der Abbildung der Modelle: Vorgangstypen müssen auf Issues mit Labels oder Projekte übersetzt werden, komplexe Statusmodelle auf das Grundraster der Kategorien, benutzerdefinierte Felder auf die schmalere Feldstruktur, Epics auf Projekte oder übergeordnete Issues, Berechtigungsschemata auf ein deutlich einfacheres Sichtbarkeitsmodell.
Genau an dieser Stelle scheitern Migrationen, wenn versucht wird, die Altstruktur eins zu eins zu erhalten. Das ist selten möglich und fast immer unklug, weil man damit denselben Konfigurationsballast in ein System bringt, das gerade wegen seines Verzichts darauf gewählt wurde. Die Empfehlung lautet daher: Migration als Aufräumgelegenheit begreifen. Es lohnt sich, vorab zu entscheiden, welcher Teil des Altbestands überhaupt mitkommt. Issues, die seit langer Zeit unbearbeitet im Rückstand liegen, gehören archiviert und nicht migriert — sie wären auch im neuen System nur Ballast, den niemand jemals anfasst.
Praktisch bewährt hat sich ein gestufter Weg: ein Team migriert zuerst und arbeitet einige Zyklen produktiv, während das Altsystem lesend verfügbar bleibt. Aus dieser Erfahrung entstehen die Konventionen für die übrigen Teams. Danach folgen weitere Teams in Wellen. Der Parallelbetrieb sollte dabei zeitlich klar begrenzt sein, denn nichts beschädigt eine Einführung so zuverlässig wie ein monatelanger Zustand, in dem beide Systeme halb genutzt werden und niemand weiß, wo die Wahrheit steht.
Drei Grenzen sollten vor der Einführung ausgesprochen werden. Erstens gibt es kein klassisches Projektmanagement: keine Balkenplanung mit Vorgänger-Nachfolger-Logik, keine automatische Terminverschiebung, keinen kritischen Pfad, keine Ressourcen- und Kapazitätsplanung, keine Budgetverfolgung. Zweitens gibt es keine eingebaute Zeiterfassung im Sinne eines Stundennachweises für Abrechnung oder Arbeitszeitdokumentation; wer das braucht, koppelt ein separates System an. Drittens ist das Berechtigungsmodell schlank — feingranulare Sichtbarkeitsregeln je Feld oder Vorgang, wie sie stark regulierte Umgebungen kennen, sind nicht der Anspruch des Produkts.
Auf der Governance-Seite sind vier Punkte im laufenden Betrieb zu führen. Die Nutzerliste gehört regelmäßig abgeglichen, weil ausgeschiedene Personen ohne automatisierte Bereitstellung im System bleiben. Zugangsschlüssel für Schnittstellen und Agenten brauchen einen Besitzer, eine Ablauffrist und eine Rotation. Der Rückstand braucht eine Aufräumroutine, sonst wächst er zu einer Halde, deren Sichtung niemand mehr zumutbar findet. Und die Exportfähigkeit sollte einmal tatsächlich geprobt worden sein — nicht erst, wenn eine Migration oder ein Auskunftsersuchen ansteht.
Das erste Szenario ist die interne Softwareentwicklung in einem Unternehmen, dessen Kerngeschäft nicht Software ist: ein Maschinenbauer mit eigener Steuerungssoftware, ein Handelsunternehmen mit eigenem Portal, ein Dienstleister mit selbst gebauter Fachanwendung. Diese Teams sind meist klein, arbeiten neben dem laufenden Betrieb und leiden besonders unter Werkzeugen, deren Pflege eine eigene Rolle erfordert. Für sie ist die niedrige Reibung von Linear ein echter Hebel, weil Statuspflege nicht zusätzlich zur Arbeit anfällt, sondern aus ihr entsteht.
Das zweite Szenario ist das Produktteam in einem Softwarehaus oder einem produktorientierten Unternehmensteil. Hier zählen Priorisierung, Vorhersagbarkeit und die Verbindung zwischen Kundenrückmeldung und Umsetzung. Die Kombination aus Triage-Eingang, Zyklen mit Auswertung und Projekt- beziehungsweise Initiativenebene deckt genau diesen Bedarf ab. Besonders wirksam ist die Anbindung des Support-Systems, weil sie Priorisierungsdiskussionen von Meinungen auf belegbare Häufigkeiten umstellt.
Das dritte Szenario ist die Agentur mit Entwicklungsanteil. Sie führt mehrere Kundenvorhaben parallel, braucht schnellen Kontextwechsel und will Kunden gelegentlich Einblick geben. Hier trägt Linear für die Umsetzungsseite gut, stößt aber an eine Grenze: Abrechnung, Stundennachweise und Budgetverfolgung fehlen. Die in der Praxis funktionierende Kombination ist ein separates System für Zeiterfassung und Abrechnung neben Linear für die Umsetzung — mit klarer Regel, welche Information wo geführt wird, und ohne den Versuch, Projektstunden über Labels oder Schätzungen nachzubauen.
Die deutlichste Fehlpassung sind nicht-technische Fachbereiche. Wenn Marketing, Personal, Vertrieb oder Verwaltung mit demselben Werkzeug arbeiten sollen, fehlen Formulare für strukturierte Eingaben, freundliche Übersichten für Gelegenheitsnutzer, Aufgabenzuweisungen mit Fälligkeitslogik und die Breite an Feldern, die diese Bereiche brauchen. Auch die Bedienphilosophie passt nicht: Eine Oberfläche, die Tastaturbedienung belohnt und Schaltflächen vermeidet, ist für Menschen, die zweimal pro Woche hineinschauen, keine Hilfe. Hier sind breitere Arbeitsmanagement-Plattformen die bessere Wahl.
Die zweite Fehlpassung betrifft Zeiterfassung und Budgetcontrolling. Wo Arbeitszeit dokumentiert, Projektstunden abgerechnet oder Budgets gegen Ist-Kosten geführt werden müssen, ist Linear das falsche System — nicht weil es schlecht wäre, sondern weil es diese Domäne bewusst nicht bedient. Behelfslösungen über Schätzwerte, Labels oder Kommentare liefern Zahlen, die nicht belastbar sind, und schaffen genau das falsche Vertrauen. Die saubere Antwort ist ein separates Fachsystem mit Schnittstellenanbindung.
Die dritte Fehlpassung ist hoher Regulierungs- oder Nachweisdruck. Wo Freigabeschritte erzwungen, Berechtigungen feingranular gesteuert, Prozessdurchsetzung nachgewiesen oder Vorgänge revisionssicher dokumentiert werden müssen, sind konfigurierbare Systeme mit erzwungenen Übergängen im Vorteil. Und wo Self-Hosting oder ein garantierter Betrieb innerhalb der EU gefordert ist, scheidet Linear unabhängig von allen anderen Kriterien aus.
Als Frühwarnzeichen haben sich drei Beobachtungen bewährt. Erstens: Es entstehen Tabellen neben dem Werkzeug, in denen jemand Informationen führt, die eigentlich hineingehören — ein sicheres Zeichen für fehlende Felder oder Auswertungen. Zweitens: Der Rückstand wächst, ohne dass jemand ihn sichtet, was auf einen unbesetzten Triage-Prozess hindeutet. Drittens: Nicht-technische Beteiligte fragen nach Status, statt selbst nachzusehen — ein Hinweis darauf, dass die Zielgruppenpassung nicht stimmt und Information zusätzlich aufbereitet werden muss.
Die Lizenzkosten werden üblicherweise je Nutzer und Monat berechnet, mit Unterschieden zwischen den Editionen und meist einem Rabatt bei jährlicher Zahlung. Belastbar wird eine Kalkulation aber erst, wenn weitere Posten einbezogen werden. Dazu zählen die Nutzerzählung und ihre Feinheiten — wie werden Gäste, Externe und Nutzer mit reinem Leserecht behandelt, gibt es günstigere Rollen für Gelegenheitsnutzer? Diese Frage entscheidet in Agenturen und Organisationen mit vielen Beteiligten oft mehr über die Gesamtkosten als der Grundpreis.
Hinzu kommen die begleitenden Systeme: ein separates Werkzeug für Zeiterfassung und Abrechnung, wenn das gebraucht wird; ein Auswertungswerkzeug, wenn die eingebauten Kennzahlen nicht reichen; eine Automatisierungsplattform, wenn Schnittstellenanbindungen nicht selbst entwickelt werden sollen. Weiter zu berücksichtigen sind der Migrationsaufwand aus dem Altsystem, der Aufwand für Konventionen und Einweisung sowie der einmalige, regelmäßig unterschätzte Aufwand für Datenschutzprüfung, Eintrag im Verzeichnis der Verarbeitungstätigkeiten und Abstimmung mit der Arbeitnehmervertretung. Und schließlich der Betriebsaufwand: Nutzerpflege, Schlüsselverwaltung, Rückstandshygiene, regelmäßige Überprüfung von Rechten und Anbindungen.
Der erste Prüfpunkt ist die Frage, wo Daten gespeichert und verarbeitet werden. Bei einem US-Anbieter ohne Self-Hosting ist von einer Verarbeitung außerhalb der EU auszugehen, sofern der Anbieter nicht ausdrücklich Optionen zur Datenresidenz anbietet. Ob solche Optionen bestehen, für welche Editionen sie gelten und welche Datenarten sie umfassen, ist produkt- und stichtagsabhängig und muss konkret beim Anbieter erfragt werden — pauschale Aussagen dazu sind unseriös. Wichtig ist zudem die Unterscheidung zwischen Inhaltsdaten und der Verarbeitung von Metadaten, Protokolldaten, Sicherungskopien und Supportzugriffen, die abweichend geregelt sein kann.
Weil der Anbieter dem Recht eines Drittlandes unterliegt, ist der Drittlandtransfer gesondert zu betrachten. Rechtlich stützt sich die Übermittlung in der Regel auf die einschlägigen Angemessenheits- beziehungsweise Transfermechanismen, ergänzt um vertragliche und technische Garantien. Grundlage jeder Nutzung ist ein Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen. Beides — Transfermechanismus und Vertrag — gehört in die Dokumentation und in das Verzeichnis der Verarbeitungstätigkeiten. Ob zusätzlich eine Datenschutz-Folgenabschätzung erforderlich ist, hängt vom konkreten Verarbeitungsumfang ab und sollte geprüft werden.
Ein Punkt, der regelmäßig übersehen wird, sind Subunternehmer. Moderne Cloud-Dienste stützen sich auf eine Kette weiterer Anbieter: Infrastruktur, Datenbankbetrieb, Suchdienste, Fehlerüberwachung, Support-Plattformen, E-Mail-Versand und zunehmend Anbieter von Sprachmodellen für die KI-Funktionen. Diese Liste ist Bestandteil des Vertragswerks, ändert sich aber im Laufe der Zeit. Zu klären ist, wie über Änderungen informiert wird, welche Widerspruchsmöglichkeit besteht und ob die KI-Funktionen einen zusätzlichen Verarbeiter in die Kette bringen, der gesondert zu bewerten ist. Wer letzteres nicht möchte, sollte prüfen, ob sich diese Funktionen abschalten lassen.
Weil ein Issue-Tracker protokolliert, wer wann welches Issue angelegt, verschoben, kommentiert und abgeschlossen hat, und weil die eingebauten Auswertungen Durchsatz und Bearbeitungsdauern sichtbar machen, ist Linear grundsätzlich geeignet, Verhalten und Leistung zu überwachen — unabhängig davon, ob das beabsichtigt ist. In Deutschland löst diese Eignung in Betrieben mit Betriebsrat die Mitbestimmung nach § 87 BetrVG aus. Der pragmatische Weg ist, die Arbeitnehmervertretung früh einzubinden und in einer Betriebsvereinbarung festzuhalten, wofür Kennzahlen genutzt werden und wofür ausdrücklich nicht — insbesondere, dass keine individuelle Leistungsbewertung erfolgt. Für Österreich und die Schweiz gelten sinngemäß eigene Regelungen, die separat zu prüfen sind.
Auf inhaltlicher Seite ist eine schlichte Inhaltsrichtlinie die wirksamste Maßnahme. In Issue-Beschreibungen und Kommentaren landet erfahrungsgemäß mehr, als hineingehört: Kundendaten aus Fehlerberichten, Auszüge aus Protokolldateien mit personenbezogenen Inhalten, Zugangsdaten, Screenshots mit Echtdaten. Die Regel sollte lauten: keine besonderen Kategorien personenbezogener Daten, keine Zugangsdaten, keine Echtdatenauszüge in Anhängen, personenbezogene Angaben nur, soweit für die Bearbeitung erforderlich. Diese Regel muss in die Einweisung und in die Vorlagen für Fehlerberichte, damit sie im Alltag ankommt.
Wenn Datenhoheit ein hartes Kriterium ist, führt der Weg zu Werkzeugen, die entweder in der EU betrieben werden oder selbst gehostet werden können. Auf der Self-Hosting-Seite sind drei Optionen in der Praxis besonders relevant. GitLab ist die naheliegendste Wahl für Entwicklungsteams, weil es Quellcode-Verwaltung, Build-Automatisierung und Arbeitsverfolgung in einem selbst betreibbaren System bündelt; die Arbeitsverfolgung ist schwächer als bei spezialisierten Werkzeugen, dafür entfällt eine ganze Schnittstelle. Jira in der Data-Center-Variante bleibt die Antwort für Organisationen, die die Konfigurationstiefe von Jira brauchen und gleichzeitig im eigenen Rechenzentrum betreiben müssen — mit entsprechendem Betriebs- und Lizenzaufwand. OpenProject ist eine quelloffene Option mit deutschem Ursprung, die klassisches Projektmanagement und agile Arbeitsverfolgung verbindet und sowohl selbst gehostet als auch in europäischen Rechenzentren betrieben werden kann.
Bei allen Self-Hosting-Varianten gilt dieselbe ehrliche Gegenrechnung: Sie bieten maximale Datenhoheit und keine Drittlandproblematik, verlagern aber Betrieb, Aktualisierung, Sicherung, Verfügbarkeit und Sicherheitspflege vollständig in die eigene Verantwortung. Für Organisationen ohne eigene Betriebskapazität ist das selten die günstigere Rechnung — für solche mit vorhandener Infrastruktur und hohen Souveränitätsanforderungen dagegen häufig die richtige Wahl. Und es gilt der Grundsatz, dass die Herkunft eines Anbieters allein kein Auswahlkriterium ist: Geprüft werden sollte immer die konkrete Vertrags- und Betriebsgestaltung, nicht der Firmensitz auf dem Briefkopf.
