Linear stap voor stap: team, cycles, roadmap en GitHub-koppeling
Linear is een tool voor productbeheer die vanaf dag één werkt: issues, cycles, projecten en roadmaps zonder wekenlange configuratie.
👁 116 keer gelezen
Linear is een tool voor productbeheer die gebouwd is op snelheid: issues, cycles, projecten en roadmaps werken vanaf de eerste dag, zonder weken configureren. Deze handleiding leidt je door de eerste setup van een workspace voor je team, volgens de officiële Linear-documentatie.
Voordat je begint: stel drie regels vast
Linear werkt meteen, maar je team heeft een paar gezamenlijke afspraken nodig om te voorkomen dat de tool weer een lijst wordt die niemand leest. Stel vast vóór de eerste cycle:
- wie en wanneer triage bekijkt, bijvoorbeeld één persoon elke ochtend,
- wat prioriteiten betekenen, zodat “urgent” niet alles betekent,
- hoe jullie branches in code noemen, zodat de GitHub-integratie automatisch statussen bijwerkt.
Schrijf deze afspraken op één plek op, bij voorkeur in de teambeschrijving in Linear zelf.
Stap 1. Workspace en team
Na het aanmaken van je account maak je een workspace voor je bedrijf en je eerste team. Een team in Linear is een werkeenheid, bijvoorbeeld een product, mobiele app of afdeling. Elk team heeft eigen issues, statussen en cycles. Voor een klein bedrijf is één team in het begin meer dan genoeg.
Als je overstapt van een andere tool, beschrijft de Linear-documentatie hoe je issues uit een bestaand systeem importeert.
Stap 2. Issues
Een issue is de basiseenheid van werk: een bug, taak of idee. Het heeft een titel, beschrijving, verantwoordelijke persoon, prioriteit en status. Linear is ontworpen voor sneltoetsen, dus bijna alles doe je zonder muis: je maakt een issue aan, wijzigt de prioriteit, wijst iemand toe. De volledige lijst met sneltoetsen vind je in de app-help. Teams beschrijven dat je met sneltoetsen tientallen issues in een paar minuten kunt ordenen.
Stap 3. Cycles, ofwel sprints zonder gedoe
Cycles zijn herhalende werkperiodes, het equivalent van sprints. Je stelt hun lengte in, de startdag en wat er moet gebeuren met onafgemaakte taken. Onafgemaakte issues kunnen automatisch naar de volgende cycle gaan, dus niemand hoeft ze elke twee weken handmatig over te zetten. Een goede start is tweewekelijkse cycles en de eerste cycle gevuld met issues die klaar zijn om aan te werken.
Stap 4. Projecten en roadmap
Projecten zijn voor langere initiatieven, vaak over meerdere teams heen, bijvoorbeeld een nieuwe app-versie. Een project verzamelt issues, toont voortgang en laat je updates publiceren, zodat de baas niet hoeft te vragen hoe het gaat tijdens meetings. Uit projecten bestaat de roadmap die zichtbaar is voor het hele bedrijf.
Stap 5. Triage, ofwel de inbox
Issues die gemaakt zijn door integraties of door mensen buiten het team komen eerst in triage terecht. Dit is een inbox die iemand regelmatig bekijkt en beslist: naar de huidige cycle, naar de backlog, of afwijzen. Hierdoor raakt de takenlijst van het team niet verstopt met issues die niemand heeft bekeken.
Stap 6. Koppeling met GitHub
De integratie schakel je in bij instellingen, in de sectie integraties. Linear koppelt issues aan pull requests via branchnamen, titels of keywords en wijzigt zelf de status van het issue op basis van wat er in de code gebeurt. Je kunt ook issues synchroniseren tussen repository en team. Tip uit de praktijk: de betrouwbaarste koppeling geeft een branchnaam volgens de Linear-conventie.
Voorbeeld: eerste week van een team van vijf personen
Dag één: workspace, één team, import van issues uit de oude spreadsheet. Dag twee: review van issues, prioriteiten, verdeling over huidige cycle en backlog. Dag drie: koppeling met GitHub en vaststellen van branchnaam-conventie. Vanaf de tweede week stopt het team met vragen wie waaraan werkt, omdat het zichtbaar is in de cycle.
Bij zo’n implementatie hangt het meeste af van de tweede dag, dus van de issue-review. Een team dat meteen prioriteiten vaststelt en uitstelt wat niet urgent is, begint de eerste cycle met een realistisch plan. Een team dat alles uit de oude spreadsheet in de cycle gooit, heeft na twee weken een gevoel van mislukking, hoewel het probleem alleen te optimistische planning was.
Meest voorkomende fouten
- Te veel teams bij de start in een klein bedrijf.
- Onbewaakte triage, die verandert in een vuilnisbelt.
- Geen branchnaam-conventie, waardoor statussen niet automatisch updaten.
Hoe je de eerste cycle evalueert
Na de eerste cycle stel je jezelf drie vragen. Hoeveel geplande issues zijn gesloten, want dat is de eerste realistische maat van wat er in twee weken past. Is triage regelmatig bekeken. Zijn statussen automatisch bijgewerkt na het mergen van code, of moest iemand ze handmatig verplaatsen.
De eerste cycle is bijna altijd overplanned. Dat is normaal en daar doe je het juist voor: de tweede cycle plan je op basis van data, niet van optimisme.
Als je team overstapt van een andere tool, geef het dan twee, drie cycles om te wennen voordat je beoordeelt of de verandering de moeite waard was. De eerste weken zijn altijd langzamer, omdat mensen sneltoetsen en een nieuw werkritme leren.
More on this from HELDER
handleidingen·Hotel Lobby AI maken: kosten, tools en promptsHotel Lobby AI is een virale TikTok-trend waarbij twee personen of dieren 'rappen' in een oranje studio. Zo maak je het met templates of motion transfer.