Productbacklog: tips voor het samenstellen en prioriteren

Een agile backlog met goede prioriteiten maakt niet alleen release- en iteratieplanning eenvoudiger, het maakt ook alle dingen duidelijk waar je team tijd aan wil besteden, inclusief intern werk dat de klant nooit zal merken. Dit helpt verwachtingen te scheppen bij belanghebbenden en andere teams, vooral wanneer ze je extra werk opleveren, en maakt engineeringtijd een vast asset.

Een productbacklog is een lijst met werk op basis van prioriteit voor het ontwikkelteam, gebaseerd op de productroadmap en de bijbehorende vereisten. De belangrijkste items worden bovenaan de productbacklog weergegeven, zodat het team weet wat het als eerste moet leveren. Het ontwikkelteam werkt de backlog niet door in het tempo van de producteigenaar en de producteigenaar pusht geen werk naar het ontwikkelteam. In plaats daarvan haalt het ontwikkelteam werk op uit de productbacklog wanneer er capaciteit voor is, hetzij continu (Kanban) of door iteratie (Scrum).

In het Scrum-framework is de productbacklog van Scrum een gestructureerde en zorgvuldig bijgehouden lijst die door de Scrum-producteigenaar wordt gebruikt als leidraad voor de taken van het ontwikkelteam.

Jira-scrumborden uitproberen

Bewaar alles in één issuetracker: gebruik niet meerdere systemen om bugs, vereisten en technische werkitems op te sporen. Als het werk betreft voor het ontwikkelteam, bewaar het dan in één backlog.

Een goed beheerde productbacklog kan tal van voordelen opleveren voor het ontwikkelteam. Enkele van de belangrijkste voordelen zijn:

• Verbeterde prioritering: Een productbacklog helpt ervoor te zorgen dat de meest kritieke taken als eerste worden uitgevoerd.
• Verhoogde efficiëntie: Door taken te prioriteren op basis van feedback van klanten en bedrijfsdoelstellingen, kunnen teams ervoor zorgen dat ze aan de meest waardevolle taken werken.
• Betere communicatie: Een productbacklog zorgt ervoor dat iedereen op één lijn zit en naar dezelfde doelen toewerkt.
• Minder afval: Door taken te prioriteren op basis van feedback van klanten en bedrijfsdoelstellingen, kunnen teams verspilling verminderen en ervoor zorgen dat ze niet werken aan taken die niet waardevol zijn.
• Verbeterde klanttevredenheid: Door taken te prioriteren op basis van feedback van klanten, kunnen teams ervoor zorgen dat ze de gewenste functies en functionaliteit aan klanten leveren.

Over het algemeen is een goed beheerde productbacklog essentieel voor agile productontwikkeling. Een productbacklog zorgt ervoor dat teams aan de meest waardevolle taken werken en dat iedereen op één lijn zit en dezelfde doelen nastreeft.

De roadmap en vereisten van een team vormen de basis voor de productbacklog. Roadmap-initiatieven vallen uiteen in verschillende epics, en elk epic heeft verschillende vereisten en userstory's. Laten we eens kijken naar de roadmap voor een fictief product genaamd Teams in Space.

Aangezien de Teams in Space-website het eerste initiatief in de roadmap is, willen we dat initiatief opsplitsen in epics (hier weergegeven in groen, blauw en groenblauw) en userstory's voor elk van die epics.

De producteigenaar organiseert vervolgens elk van de userstory's in één lijst voor het ontwikkelteam. De producteigenaar kan ervoor kiezen om eerst een complete epic te leveren (links). Of het kan belangrijker zijn voor het programma om het boeken van een vlucht met korting te testen waarvoor story's uit verschillende epics nodig zijn (rechts). Zie beide voorbeelden hieronder.

Wat kan de prioritering van een producteigenaar beïnvloeden?

• Prioriteit van een klant
• Urgentie om feedback te krijgen
• Relatieve implementatieproblemen
• Symbiotische relaties tussen werkitems (bijv. B is makkelijker als we eerst A doen)

Een effectieve prioritering van de productbacklog zorgt ervoor dat de meest kritieke taken eerst worden aangepakt, waarbij de autonomie van het team wordt afgestemd op de eisen van de producteigenaar.

Hoewel de producteigenaar de taak heeft om de backlog te prioriteren, gebeurt dit niet in een vacuüm. Effectieve producteigenaren vragen input en feedback van klanten, ontwerpers en het ontwikkelteam om ieders werklast en de productlevering te optimaliseren.

Een productbacklog maken is een cruciaal aspect van agile productontwikkeling. Dit proces omvat het opstellen van een productroadmap, items opnemen in de productbacklog en communiceren met het team.

Een productroadmap is een plan op hoog niveau waarin de visie, doelen en doelstellingen voor een product worden uiteengezet. De roadmap dient als basis voor de productbacklog en zorgt ervoor dat iedereen op één lijn zit en dezelfde doelen nastreeft.

Om een productroadmap op te stellen, moet je de visie en missie van een product definiëren. Identificeer vervolgens de belangrijkste doelstellingen en doelen die moeten worden bereikt. Verdeel tot slot de doelstellingen in kleinere, beheerbare taken die kunnen worden toegevoegd aan de productbacklog.

Zodra de productroadmap is opgesteld, is het tijd om te beginnen met het opnemen van items in de productbacklog. Deze items kunnen bestaan uit functies, userstory's, bugs, ontwerpwijzigingen en technische schulden.

Als je items in de productbacklog opneemt, voeg dan een duidelijke omschrijving toe van elk item met alle relevante informatie, zoals de geschatte tijd en benodigde middelen. Het is ook essentieel om de items te prioriteren op basis van feedback van klanten, verzoeken en bedrijfsdoelstellingen. Dit zorgt ervoor dat het ontwikkelteam werkt aan taken die de meeste waarde opleveren.

Effectieve communicatie is van cruciaal belang bij het maken van een productbacklog. De producteigenaar moet nauw samenwerken met het ontwikkelingsteam om ervoor te zorgen dat iedereen de productbacklog en de prioriteiten begrijpt. De producteigenaar moet ook communiceren met andere teams, zoals die voor verkoop en marketing, om ervoor te zorgen dat iedereen op één lijn zit en dezelfde doelen nastreeft.

Regelmatige vergaderingen en updates zorgen ervoor dat iedereen op één lijn zit en dat de productbacklog effectief wordt beheerd.

Heb je nog steeds hulp nodig? Bekijk de gratis sjabloon voor productbacklogs uit Jira.

Prioritering van de backlog is essentieel om ervoor te zorgen dat het ontwikkelteam zich concentreert op taken die maximale impact hebben. Zo pak je dat aan:

Verschillende technieken voor het prioriteren van een backlog, zoals MoSCoW en gewogen scores, kunnen teams helpen om taken effectief te beheren en te ordenen. Het prioriteringsproces omvat het regelmatig herzien en bijstellen van doelen zodat ze weer aansluiten op de situatie in het bedrijf.

• Identificeer de functies of oplossingen die de hoogste waarde hebben voor je gebruikers.
• Gebruik feedback van klanten, enquêtes of analyses om prioriteiten te stellen.

• Prioriteer items die bruikbare inzichten opleveren voor het team of de belanghebbenden.
• Als je bijvoorbeeld een nieuwe functie vroegtijdig test, kun je later tijd en middelen besparen.

• Zorg voor een balans tussen korte, eenvoudige taken en complexere langetermijnprojecten.
• Weeg de verhouding tussen inspanning en impact af om ervoor te zorgen dat middelen verstandig worden besteed.

• Bepaal welke taken voltooid moeten worden voordat je aan andere taken begint.
• Stroomlijn workflows door eerst het basiswerk te voltooien.

Betrouwbare hulpmiddelen die de prioritering van backlogs ondersteunen, kunnen de productontwikkeling stroomlijnen en de efficiëntie verbeteren. De producteigenaar leidt de prioritering, maar door het ontwikkelteam, de ontwerpers en belanghebbenden erbij te betrekken, zorg je voor een gedeeld inzicht in prioriteiten. Door regelmatig in gesprek te gaan, zorg je voor afstemming en wordt de besluitvorming verbeterd.

Tip: Gebruik kaders voor prioritering zoals de MoSCoW-methode (verdeelt projecttaken in de categorieën absoluut noodzakelijk, noodzakelijk, wenselijk en niet haalbaar) of gewogen scores om objectieve beslissingen te nemen op basis van gegevens. Teams kunnen hun eigen unieke prioriteitskaders implementeren met behulp van de flexibele prioriteringsfunctie in Jira Product Discovery.

Zodra de productbacklog is opgebouwd, is het cruciaal om deze regelmatig te onderhouden om gelijke tred te houden met het programma. Producteigenaren moeten de backlog vóór elke iteratieplanningsmeeting bekijken om ervoor te zorgen dat de prioritering correct is en feedback van de laatste iteratie is opgenomen. Regelmatige beoordeling van de backlog, in de context van agile vaak 'product backlog refinement' genoemd, zorgt ervoor dat taken worden afgestemd op de inzichten van belanghebbenden en bereidt het team voor op de komende sprint (sommigen gebruiken de term backlogverfijning).

Zodra de backlog groter wordt, moeten producteigenaren de backlog groeperen in items op korte en lange termijn. Items op korte termijn moeten volledig worden uitgewerkt, voordat ze als zodanig worden gelabeld. Dit betekent dat volledige userstory's zijn opgesteld, samenwerking met ontwerp en ontwikkeling is uitgezocht en schattingen door het ontwikkelteam zijn gemaakt.

Items op langere termijn kunnen een beetje vaag blijven, hoewel het een goed idee is om een ruwe schatting van het ontwikkelteam te krijgen om ze te helpen prioriteren. Het sleutelwoord hier is 'ruw': schattingen veranderen zodra het team die items op langere termijn volledig begrijpt en eraan begint te werken.

De backlog dient als verbinding tussen de producteigenaar en het ontwikkelteam. De producteigenaar kan werk in de backlog opnieuw prioriteren op basis van feedback van klanten, verfijnde schattingen en nieuwe vereisten. Maar als het werk eenmaal aan de gang is, moeten veranderingen tot een minimum worden beperkt, omdat ze het ontwikkelteam storen en een negatieve invloed hebben op de focus, de flow en het moreel.

Tip: Zodra de backlog verder groeit dan de capaciteit van het team op de lange termijn, is het oké om issues af te sluiten waar het team nooit aan toe zal komen. Markeer die issues met een specifieke beslissing, zoals 'niet in scope', in de issue tracker van het team om deze later voor onderzoek te kunnen gebruiken.

Antipatronen om op te letten

• De producteigenaar prioriteert de backlog aan het begin van een project, maar past deze niet aan naarmate er feedback binnenkomt van ontwikkelaars en belanghebbenden.
• Het team beperkt items op de backlog tot items die klantgericht zijn.
• De backlog wordt bewaard als een document dat lokaal wordt opgeslagen en niet vaak wordt gedeeld, waardoor geïnteresseerde partijen geen updates kunnen krijgen.

Slimme producteigenaren houden de productbacklog van hun programma rigoureus bij, waardoor het een betrouwbaar en deelbaar overzicht van de werkitems voor een project wordt.

Belanghebbenden zullen prioriteiten uitdagen, en dat is een goede zaak. Door discussie te bevorderen over wat belangrijk is, worden ieders prioriteiten gesynchroniseerd. Deze discussies bevorderen een cultuur van groepsprioritering, zodat iedereen dezelfde mentaliteit over een programma deelt.

Een agile backlog met goede prioritering maakt duidelijk waar het team tijd aan wil besteden en legt de nadruk op zichtbare en interne taken. De productbacklog dient ook als basis voor iteratieplanning. Alle werkitems moeten in de backlog worden opgenomen: userstory's, bugs, ontwerpwijzigingen, technische schulden, verzoeken van klanten, actie-items uit de retrospective enz. Op deze manier kan je team ervoor zorgen dat de werkitems van iedereen worden opgenomen in de algemene discussie voor elke iteratie. Teamleden kunnen vervolgens afwegingen maken met de producteigenaar voordat ze een iteratie starten met volledige kennis van alles wat er moet gebeuren.

Tip: Producteigenaren bepalen de prioriteit van werkitems in de backlog, terwijl het ontwikkelteam de snelheid bepaalt. Dit kan een gespannen relatie opleveren voor nieuwe producteigenaren die werk naar het team willen 'pushen'. In dit artikel worden de limieten en de flow van het werk in uitvoering uitgelegd.