Taak en ticket — wat is het, trackingsystemen en werken met taken

Wat is een taak en ticket?

Taak (van Engels task) — een werkeenheid geregistreerd in een trackingsysteem. Bevat beschrijving, prioriteit (Critical, High, Medium, Low), uitvoerder, deadline en status. In mobiele ontwikkeling kan een taak zijn: “Profielscherm met avatar toevoegen”, “Feedpaginatie implementeren” of “TargetSdk-versie bijwerken naar 35”. Elke taak is gekoppeld aan een project, sprint en een specifieke ontwikkelaar of team.

Ticket (van Engels ticket) — een bredere entiteit. Een ticket kan een bugrapport zijn (“App crasht bij schermrotatie op Android 14”), een functieverzoek (“Donkere modus ondersteuning toevoegen”), een melding aan technische ondersteuning (“Pushmelding komt niet aan”) of een taak van een manager (“Crashrate rapport voor de maand voorbereiden”). Het verschil tussen een taak en een ticket is vaag: in Jira zijn beide concepten verenigd in Issue. Het belangrijkste verschil: een taak is altijd werk met een uitvoerder, een ticket kan een verzoek zijn zonder specifieke uitvoerder tot het triage-moment.

In Scrum en Kanban zijn taken het belangrijkste element van de backlog. Elke taak moet voldoen aan het INVEST-criterium (Independent, Negotiable, Valuable, Estimable, Small, Testable). Onafhankelijke taken kunnen in willekeurige volgorde worden uitgevoerd. Schatbaar — het team kan de werkinspanning inschatten. Klein — past in één sprint. Testbaar — heeft duidelijke acceptatiecriteria. Grote taken (epics) worden opgedeeld in kleinere delen tot alle criteria zijn vervuld.

Soorten taken in mobiele ontwikkeling

Feature — nieuwe functionaliteit van de app. Voorbeeld: “Inlogscherm via biometrie (Face ID / Touch ID)”. Feature-taken zijn altijd gekoppeld aan een user story en hebben Acceptatiecriteria. Schatting — in story points (1, 2, 3, 5, 8, 13). Bug — een defect gevonden tijdens ontwikkeling of testen. Prioriteit van een bug-ticket wordt bepaald door severity (crash → Critical, UI-bug → Medium, typfout → Low). In mobiele ontwikkeling is een crashrate boven 0,1% een kritieke bug en vereist onmiddellijke reparatie.

Tech Debt / Chore — technische taken zonder zichtbaar effect voor de gebruiker: bibliotheken bijwerken (Dependency Bump), refactoring (Migratie van ViewPager naar ViewPager2), CI/CD configureren, tests schrijven. Tech Debt-taken worden vaak onderschat, hoewel volgens gegevens van Stripe 2025 tot 30% van de tijd van een mobiel team gaat naar onderhoud en aflossing van technische schuld. Het negeren van Tech Debt leidt tot meer bugs en vertraging van de ontwikkeling van nieuwe functies.

Aanvullende typen: Spike (onderzoekstaak — nieuwe technologie bestuderen, POC schrijven), Task (al het werk dat niet gerelateerd is aan code — documentatie, designreview), Improvement (verbetering van bestaande functionaliteit — optimalisatie van laadtijd van scherm). In Jira worden issue-typen per project ingesteld. Standaardset voor een mobiel team: Story, Bug, Task, Improvement, Epic. Epic — een groot onderwerp dat meerdere verhalen verenigt. Voorbeeld: “E-commerce: winkelwagen en bestelling afronden”.

Levenscyclus van een taak: van creatie tot sluiting

Open (To Do) — taak aangemaakt maar niet gestart. Bevat beschrijving, Acceptatiecriteria, prioriteit. In deze status moet de taak door grooming (verduidelijking en schatting) gaan voordat deze in de sprint komt. In Progress — ontwikkelaar is begonnen met werken. In mobiele ontwikkeling is het belangrijk om commits en pull requests aan de taak te koppelen: in Jira via Smart Commits (APP-123 #comment bugfix), in GitHub/GitLab via trefwoorden in de PR-beschrijving (Closes APP-123).

In Review — code verzonden voor review. Automatische controles: CI (Gradle build, lint, unittesten), SonarQube (codekwaliteit), Danger (changelog, tests). Ontwikkelaar kan de volgende taak niet starten zolang de huidige taak in Review staat — dit voorkomt multitasking. QA / Testing — tester controleert op echte apparaten (Android — verschillende OS-versies en schermformaten, iOS — verschillende iPhone-modellen). Als er bugs worden gevonden, gaat de taak terug naar In Progress met een opmerking.

Done (Closed) — taak voltooid: code samengevoegd in main/master, getest, klaar voor release. Sommige teams voegen de status Deployed toe — de taak bereikt de gebruiker pas na publicatie van de build in de stores. Het is belangrijk om taken te sluiten met een opmerking over het resultaat: welke versie, welke PR, welke metrieken zijn veranderd. Volgens gegevens van Linear (2025) keren teams die taken sluiten met een beschrijving van het resultaat 40% minder vaak terug naar dezelfde taken.

De levenscyclus kan de status Blocked omvatten — de taak kan niet worden uitgevoerd vanwege een externe afhankelijkheid (wachten op ontwerp, antwoord van backend, goedkeuring manager). Geblokkeerde taken moeten een opmerking hebben met de reden en datum van de volgende controle. Wekelijkse review van geblokkeerde taken helpt bij het identificeren van systeemvertragingen in het ontwikkelingsproces. Blokkeerders langer dan 2 weken vereisen escalatie naar het niveau van de productmanager.

Trackingsystemen voor taken

Jira — industrienorm voor teams vanaf 10 personen. Ondersteunt Scrum- en Kanban-borden, geavanceerde workflow-instellingen, aangepaste velden, automatiseringen, integratie met Bitbucket/GitHub. Nadelen: overbodig voor kleine teams, trage interface, complexe configuratie. Voor mobiele projecten wordt Jira geconfigureerd met: plug-in Mobile-specific fields (Platform, OS version, Device model), integratie met TestFlight en Firebase Test Lab, automatisering van release-builds. Jira — keuze voor bedrijfsprojecten met bureaucratische processen.

Linear — moderne tracker voor productteams. Snelle interface, eersteklas ondersteuning voor sneltoetsen, ingebouwde Cycle (analoog aan sprint), integratie met GitHub en Slack. Voordelen: snelheid van taakcreatie via CMD+K, automatische toewijzing aan fasen (Triaged → Backlog → Upcoming → Current → Completed), ingebouwde documentatie en roadmaps. Linear wordt gekozen door startups en productteams die snelheid waarderen. In 2025 gebruikt 40% van de nieuwe mobiele projecten Linear.

Trello — eenvoudig Kanban-bord voor kleine teams (2-5 personen). Kaarten met checklists, labels, deadlines. Nadeel: geen sprints, beperkte analyse, moeilijk schaalbaar. YouGile — Russische tegenhanger van Trello met Kanban-borden, chat en videogesprekken. Asana — tracker met focus op projecten en tijdlijnen. De keuze van een tracker hangt af van teamgrootte, budget en voorkeuren: Jira voor enterprise, Linear voor productteams, Trello/YouGile voor startups. Belangrijk: het hulpmiddel moet uniform zijn voor het hele team — ontwerpers, ontwikkelaars, testers, managers werken in hetzelfde systeem.

Beste praktijken voor taakbeheer

Schrijf Acceptatiecriteria — acceptatiecriteria moeten concreet en verifieerbaar zijn. Slecht: “Inlogscherm werkt”. Goed: “Gebruiker voert e-mail en wachtwoord in, klikt op Inloggen. Als gegevens correct zijn — overgang naar hoofdscherm. Als onjuist — wordt foutmelding “Onjuiste e-mail of wachtwoord” weergegeven”. Acceptatiecriteria (AC) zijn een contract tussen ontwikkelaar, tester en productmanager. Zonder AC voldoet de taak niet aan Definition of Ready (DoR) en mag deze niet in de sprint komen.

Koppel alles. Commits, PR's, testcases, ontwerpmodellen (Figma), discussies in Slack — alles moet aan de taak worden gekoppeld. In Jira gebeurt dit via links in opmerkingen, in Linear — via automatische koppeling van PR. Eénklikregel: van taak naar ontwerp/code/tests — niet meer dan één klik. Ontwikkelaar opent de taak en ziet direct het model in Figma, de PR-link en testcases. Dit versnelt de onboarding van nieuwe teamleden met 30% volgens gegevens van Linear (2025).

Maak geen spooktaken. Een taak zonder beschrijving, zonder AC en zonder prioriteit is rommel. Als op de dagelijkse standup niemand zich herinnert waarom de taak is gemaakt — moet deze worden verwijderd of verduidelijkt. De 48-uursregel: als een taak 48 uur in de status In Progress heeft gestaan zonder activiteit — moet de ontwikkelaar een opmerking plaatsen over de redenen van de vertraging. Volgens gegevens van Jira (2025) wordt 60% van de taken die langer dan 3 dagen inactief zijn, uiteindelijk gesloten zonder uitvoering.

Taakdecompositie: epics, user stories en subtaken

Epic — een groot functioneel gebied dat meerdere verhalen verenigt. Voorbeeld: “Gebruiker onboarding” omvat “Welkomstscherm”, “Interesses selecteren”, “Avatar uploaden”, “Meldingen instellen”. User Story — een taak vanuit het perspectief van de gebruiker. Formaat: “Als [rol], wil ik [actie] om [waarde]”. Voorbeeld: “Als gebruiker wil ik inloggen via biometrie om niet elke keer mijn wachtwoord in te voeren”. User Story wordt geschreven door de productmanager of producteigenaar.

Subtaak (Sub-task) — decompositie van technisch werk binnen Story / Task. Voorbeeld voor Story “Profielscherm”: Sub-task 1: UI van het scherm maken (XML / SwiftUI), Sub-task 2: Koppelen aan ViewModel, Sub-task 3: Unittests schrijven, Sub-task 4: Snapshot-tests, Sub-task 5: UI-tests (Espresso / XCUITest). Decompositie regel: elke subtaak wordt in 1-2 dagen voltooid. Als de ontwikkelaar een subtaak langer schat — delen we verder. Subtaken zijn een interne teamtechniek en zijn niet zichtbaar in de productbacklog. De som van de schattingen van subtaken is niet noodzakelijk gelijk aan de schatting van de bovenliggende Story (een deel van het werk — communicatie, code review, testen).

Decompositiepiramide: Epic (Kwartaal / Halfjaar) → Feature / Story (Sprint) → Task (1-3 dagen) → Sub-task (Enkele uren). INVEST-techniek helpt bij het controleren van de decompositiekwaliteit. Als een taak niet Independent is (afhankelijk van andere) — is dat een signaal dat de decompositie onjuist is. Als een taak niet Small is (meer dan 8 story points) — moet verder worden verdeeld. Algemeen patroon: Epic → 5-15 Stories → elke Story → 3-8 Subtaken. De uiteindelijke schatting van de epic = som van de Stories-schattingen, maar de eerste sprint heeft meestal een afwijking van 20-30% in schattingen.

Veelgemaakte fouten bij het werken met taken

Fout 1: te grote taken. Een taak van 2 weken werk is een epic die moet worden gedecomposeerd. Grote taken zijn niet geschikt voor dagelijkse tracking, ze hangen wekenlang in In Progress. Regel: maximale taakgrootte — 2-3 dagen werk. Alles groter — decomponeren. Bijwerking: de ontwikkelaar voelt vooruitgang door 2-3 taken per week af te sluiten in plaats van één gigantische. Dit verhoogt de motivatie en voorspelbaarheid van deadlines.

Fout 2: gebrek aan Acceptatiecriteria. Ontwikkelaar maakte de functie, tester controleerde — alles ok. Manager: “Waar is de bewerkingsknop?” — “Niet in de taak geschreven”. Zonder AC begrijpt elke partij de taak op zijn eigen manier. Resultaat: overwerk, conflicten, gemiste deadlines. AC — contract: als er geen criteria in de taak staan — is deze niet klaar voor de sprint. Tijdens grooming wordt eerst de aanwezigheid van AC gecontroleerd. Als AC ontbreekt — wordt de taak teruggestuurd naar de productmanager voor aanpassing.

Fout 3: Tech Debt vergeten. Team doet alleen Feature-taken sprint na sprint. Na een half jaar: compilatie duurt 15 minuten, Gradle is 3 hoofdversies verouderd, tests falen op CI door deprecation. Oplossing: reserveer 20% van de teamtijd voor Tech Debt (Google SRE-praktijk “SLO-based error budget”). Maak ten minste één Tech Debt-taak per Feature-sprint aan. Verhouding: op elke 3 Feature-taken — 1 Tech Debt of Bug. Dit voorkomt ophoping van technische schuld en behoudt de ontwikkelingssnelheid.